[Issue 12542] New: No function attribute inference for recursive functions
https://d.puremagic.com/issues/show_bug.cgi?id=12542
Summary: No function attribute inference for recursive
functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2014-04-07 23:06:23 PDT ---
I've seen this being mentioned before in other bugs, but haven't been able to
find an issue proper for it.
Basically, if a function is recursive, then none of it's attributes are
inferred: It's always impure, throwing and unsafe.
//
int logOf(int n)
{
if (n)
return 1 + logOf(n/2);
return 0;
}
void main() @safe nothrow pure
{
int log = logOf(9);
}
//
Error: pure function 'D main' cannot call impure function 'main.logOf'
Error: safe function 'D main' cannot call system function 'main.logOf'
Error: 'main.logOf' is not nothrow
Error: function 'D main' is nothrow yet may throw
//
The compiler should be able to tell that logOf is nothrow and pure. I think
it's safe too: Potential risk of stack overflow aren't considered memory
unsafe, are they?
In any case it's blocking the fixing of certain function attributes, such as
those of sort, or sum.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12543] New: Class.sizeof requires the Class' definition
https://d.puremagic.com/issues/show_bug.cgi?id=12543 Summary: Class.sizeof requires the Class' definition Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2014-04-08 00:56:16 PDT --- // class SomeClass; pragma(msg, SomeClass.sizeof); // Error: class main.SomeClass is forward referenced when looking for 'sizeof' // AFAIK, you don't need to know about SomeClass, to know it's size is that of object, eg, size_t. See also: https://d.puremagic.com/issues/show_bug.cgi?id=12540 https://github.com/D-Programming-Language/phobos/pull/2074 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12542] No function attribute inference for recursive functions
https://d.puremagic.com/issues/show_bug.cgi?id=12542
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-04-08 01:13:13 PDT ---
(In reply to comment #0)
//
int logOf(int n)
{
if (n)
return 1 + logOf(n/2);
return 0;
}
void main() @safe nothrow pure
{
int log = logOf(9);
}
For attribute inference, logOf should be template function.
https://github.com/D-Programming-Language/dmd/pull/3436
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12542] No function attribute inference for recursive functions
https://d.puremagic.com/issues/show_bug.cgi?id=12542 --- Comment #2 from monarchdo...@gmail.com 2014-04-08 02:29:31 PDT --- (In reply to comment #1) For attribute inference, logOf should be template function. Oops. Sorry! https://github.com/D-Programming-Language/dmd/pull/3436 Oh, wow. I didn't expect a fix so quickly. Cool. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12543] Class.sizeof requires the Class' definition
https://d.puremagic.com/issues/show_bug.cgi?id=12543 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Version|unspecified |D2 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-04-08 02:42:48 PDT --- https://github.com/D-Programming-Language/dmd/pull/3437 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12544] New: Differences in ubyte/char enum printing
https://d.puremagic.com/issues/show_bug.cgi?id=12544
Summary: Differences in ubyte/char enum printing
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-04-08 03:24:22 PDT ---
I am not sure if this is a bug, a regression, or it's working as designed.
Currently this code shows a difference in the outputs that perhaps should not
exist:
void main() {
import std.stdio;
enum E1 : ubyte { A='a' }
E1[10] v1;
writeln(v1);
enum E2 : char { A='a' }
E2[10] v2;
writeln(v2);
writefln(%-(%c%), v2);
}
DMD 2.066alpha output:
[A, A, A, A, A, A, A, A, A, A]
aa
aa
Expected output:
[A, A, A, A, A, A, A, A, A, A]
[A, A, A, A, A, A, A, A, A, A]
aa
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12543] Class.sizeof requires the Class' definition
https://d.puremagic.com/issues/show_bug.cgi?id=12543 --- Comment #2 from github-bugzi...@puremagic.com 2014-04-08 03:45:25 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f3fea81596aa0bdb4e194f4acf480a4be07ce926 fix Issue 12543 - Class.sizeof requires the Class' definition https://github.com/D-Programming-Language/dmd/commit/1d8d43ab90df75f8eba875ac02abc352a3cf64f9 Merge pull request #3437 from 9rnsr/fix12543 Issue 12543 - Class.sizeof requires the Class' definition -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12543] Class.sizeof requires the Class' definition
https://d.puremagic.com/issues/show_bug.cgi?id=12543 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12539] Compiler crash when looking up a nonexistent tuple element in an associative array
https://d.puremagic.com/issues/show_bug.cgi?id=12539 --- Comment #2 from github-bugzi...@puremagic.com 2014-04-08 04:55:34 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8f70c6f23c8d615affd73e1a23fcb32ef5ddea59 fix Issue 12539 - Compiler crash when looking up a nonexistent tuple element in an associative array https://github.com/D-Programming-Language/dmd/commit/3001fb407685e05f68e49742ef43192cf692ee97 Merge pull request #3435 from 9rnsr/fix12539 Issue 12539 - Compiler crash when looking up a nonexistent tuple element in an associative array -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12539] Compiler crash when looking up a nonexistent tuple element in an associative array
https://d.puremagic.com/issues/show_bug.cgi?id=12539 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12509] Compiler performance highly depends on declared array size - for struct with long static array of structs
https://d.puremagic.com/issues/show_bug.cgi?id=12509 --- Comment #5 from github-bugzi...@puremagic.com 2014-04-08 05:26:05 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f111434251af84e90abc709a49527ec76b9e1a97 fix Issue 12509 - Compiler performance highly depends on declared array size - for struct with long static array of structs https://github.com/D-Programming-Language/dmd/commit/db2291fc32b08187fb5862eefe3160a3e6b3dd90 Merge pull request #3425 from 9rnsr/fix12509 [REG2.064] Issue 12509 - Compiler performance highly depends on declared array size - for struct with long static array of structs -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12509] Compiler performance highly depends on declared array size - for struct with long static array of structs
https://d.puremagic.com/issues/show_bug.cgi?id=12509 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12544] Differences in ubyte/char enum printing
https://d.puremagic.com/issues/show_bug.cgi?id=12544 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2014-04-08 06:54:41 PDT --- The code goes through the formatRange branch of `std.format`. In format range, the code checks if it is a range of chars: - range of chars = print string (eg: aaa...) - range of non-chars = print array (eg: [A, A, A, A, A... The issue is one of determining what is a char? Currently, the code uses: is(CharTypeOf!(ElementType!T)) Which mean any type that implicitly casts to char is fair game (including structs with alias this). *Arguably*, I think `isSomeChar` would be better, as it only accepts *actual* chars. But even then, it would still accept enums whose base type is char, as technically, they *are* chars. Unfortunately, there is always ambiguity when asking to print an enum of a char or string. I don't know either if this is bug or working as designed. (I don't think it's a regression though... did you test other versions?) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12545] New: An object with .init breaks std.range.ElementType
https://d.puremagic.com/issues/show_bug.cgi?id=12545
Summary: An object with .init breaks std.range.ElementType
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: destructiona...@gmail.com
--- Comment #0 from Adam D. Ruppe destructiona...@gmail.com 2014-04-08
07:01:11 PDT ---
import std.range;
struct Foo { /* same with class btw */
void init(int a) { }
}
void main() {
Foo[] a;
pragma(msg, ElementType!(typeof(a))); // void(int a)
auto s = stride(a, 3); // *
}
* std/range.d(2188): Error: variable
std.range.stride!(Foo[]).stride.Result.front.val cannot be declared to be a
function
Since ElementType checks Type.init.front.init, it gets a function type instead
of the element type - void(int) instead of Foo.
Then, stride (among many others) uses ElementType!Range in the function
definitions, we get big errors when the higher order range functions are
declared with them in places.
I'm not sure if this is a bug per se, and is easily worked around by renaming
the function from init to anything else, but it is pretty easy to break and
hard to track down the cause if you don't have an idea of the .init idiom used
in phobos.
I kinda feel that declaring a member called init ought to be disallowed, so
Type.init can be trusted in all code.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12546] New: DMD does not generate required symbols for linker
https://d.puremagic.com/issues/show_bug.cgi?id=12546
Summary: DMD does not generate required symbols for linker
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tomerfil...@gmail.com
--- Comment #0 from Tomer Filiba tomerfil...@gmail.com 2014-04-08 07:05:29
PDT ---
When using templates defined in another module (via an alias), all the files
must be compiled together or link errors ensue. For example:
Compile together
$ dmd main.d mymodule.d echo ok
ok
Compile separately
$ dmd -c main.d dmd -c mymodule.d dmd main.o mymodule.o
main.o:(.data._D78TypeInfo_S8mymodule40__T15TypedIdentifierVAyaa6_4d7954797065Z15TypedIdentifier6__initZ+0x40):
undefined reference to
`_D8mymodule40__T15TypedIdentifierVAyaa6_4d7954797065Z15TypedIdentifier8__xopCmpFKxS8mymodule40__T15TypedIdentifierVAyaa6_4d7954797065Z15TypedIdentifierKxS8mymodule40__T15TypedIdentifierVAyaa6_4d7954797065Z15TypedIdentifierZi'
main.o:(.data._D78TypeInfo_S8mymodule40__T15TypedIdentifierVAyaa6_4d7954797065Z15TypedIdentifier6__initZ+0x48):
undefined reference to
`_D8mymodule40__T15TypedIdentifierVAyaa6_4d7954797065Z15TypedIdentifier8toStringMxFZAya'
collect2: error: ld returned 1 exit status
--- errorlevel 1
This screws up our build system (which builds each file separately)
Here is the code for reproducing this error:
=
main.d
=
import mymodule;
void main()
{
int dict[MyType];
auto x = dict[MyType(0)];
}
=
mymodule.d
=
module mymodule;
import std.string;
struct TypedIdentifier(string NAME) {
int value;
this(int val) {
value = val;
}
int opCmp(ref const int rhs) const {
return value rhs ? 1 : (value rhs ? -1 : 0);
}
string toString() const {
return format(%s(%s), NAME, value);
}
}
alias MyType = TypedIdentifier!MyType;
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10413] .init incorrectly accepts any expression
https://d.puremagic.com/issues/show_bug.cgi?id=10413 --- Comment #3 from monarchdo...@gmail.com 2014-04-08 08:12:41 PDT --- (In reply to comment #2) instance of having to pulling out the typeof. I mean instead of having to pull out the typeof. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10413] .init incorrectly accepts any expression
https://d.puremagic.com/issues/show_bug.cgi?id=10413 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2014-04-08 08:10:53 PDT --- (In reply to comment #1) With constructions like: template Foo(T...) T[0].init is OK if T[0] is a type, but if it is a value, it won't compile. If the template code doesn't make sense, then it doesn't compile. Seems fine to me. It is in fact pretty bizarre that 2.init == 0, so this should probably be changed. .init is a static property, and as such, can be called on either type or instance, just the same way you can write assert(1.max == 0x7FF). As a matter of fact, I'm pretty sure I've seen this used before, instance of having to pulling out the typeof. I'm not sure changing this would be correct. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7597] Statically disallow a init() method in structs
https://d.puremagic.com/issues/show_bug.cgi?id=7597
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2014-04-08 08:19:34 PDT ---
(In reply to comment #0)
Timon Gehr shows a case where defining a struct init method is useful, this
code compiles unless you de-comment the struct init. But maybe this is just a
bug in the implementation of @disable:
struct Foo {
@disable this();
// @disable enum init = 0;
}
void main() {
Foo f = Foo.init;
}
Arguably, the Foo f = Foo.init; *should* be guaranteed to *always* work.
Finding a way to break it would be *catastrophic* for generic phobos code.
The formulation is meant as a verbose way of saying
- YES! I know that Foo is const/hasDisableThis, and I know I should be
initializing it to an explicit value. But for gods sake, this is generic code
and I need an instance regardless! Just use T.init. I'll assume the
consequences.
More often than not, it is need for traits, where f would never be used
anyways.
It is also safer alternative to void initialization (that don't work with const
anyways): should a throwing function be located between the declaration, and
the subsequent emplace construction, at least, the destructor will be called on
non-garbage, and the specs *do* say that T.init should always be destroyable.
See also:
https://d.puremagic.com/issues/show_bug.cgi?id=8752
Where Kenji suggests that some uses of Foo f = Foo.init; be made unsafe under
certain situations.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10828] datetime toString functions should accept sink
https://d.puremagic.com/issues/show_bug.cgi?id=10828 Marco Leise marco.le...@gmx.de changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #1 from Marco Leise marco.le...@gmx.de 2014-04-08 09:21:09 PDT --- The problem will move on to the checks of the format specifiers, which want to throw exceptions, which means the GC could in turn throw InvalidMemoryOperationError. Now one could fix the GC to allow exceptions to be thrown from ~this(), but basically if the dtor really fails, your program is possibly in an invalid state. Maybe my thinking is wrong, but I'd say it should either complete or terminate the application like AssertError, InvalidMemoryOperationError or OutOfMemoryError do. That said, the logging should be wrapped in a try-catch here: It is more important that the rest of the dtor succeeds. About the GC, I don't know what to do. It would be best if the implementation could allow further allocations while the collection is running. Like when you create a new pool for the allocations and join it with the old one after collection. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10828] datetime toString functions should accept sink
https://d.puremagic.com/issues/show_bug.cgi?id=10828 --- Comment #2 from monarchdo...@gmail.com 2014-04-08 10:06:58 PDT --- (In reply to comment #1) The problem will move on to the checks of the format specifiers, which want to throw exceptions, which means the GC could in turn throw InvalidMemoryOperationError. An exception is only thrown if the format string is invalid. Furthermore, there *is* a toString which simply does not take format. So *that* should never throw (though it might not actually be nothrow, due to UTF). Besides, GC and destructors is only one aspect of the issue. Having a `toString` that takes a sink is just good design overall. Avoids gratuitous allocations. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8370] invalid deprecation error with -release -inline -noboundscheck
https://d.puremagic.com/issues/show_bug.cgi?id=8370 Saurabh Das saurabh@gmail.com changed: What|Removed |Added CC||saurabh@gmail.com --- Comment #2 from Saurabh Das saurabh@gmail.com 2014-04-08 11:23:17 PDT --- Similar error: echo ' import std.mmfile; ' test.d dmd -c -de -release -inline -noboundscheck test.d /usr/include/dmd/phobos/std/mmfile.d(344): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.linux.sys.mman for non-POSIX extensions Removing any of '-release', '-inline' or '-noboundscheck' allows the code to compile. [Using DMD64 D Compiler v2.065 on Linux] -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12548] New: Safer malloc/calloc/realloc wrappers in Phobos
https://d.puremagic.com/issues/show_bug.cgi?id=12548 Summary: Safer malloc/calloc/realloc wrappers in Phobos Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2014-04-08 12:42:05 PDT --- In my D code for various reasons I sometimes need or wants to use C memory allocating functions, the malloc/calloc/realloc. But in D they force the usage of a cast(), that I prefer to avoid. And often you need to specify the type two times, like this (such code is not DRY, and this leads to bugs): cast(T*)malloc(typeof(T).sizeof * 10); So I suggest to add to Phobos three little wrappers around those functions that allow remove those casts (this can't be done with the alloca function), that are safer than the C functions: cMalloc!T(n) cCalloc!T(n) cRealloc(ptr, n) cRealloc doesn't need the type because it's inferred from the given pointer. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12547] New: floor/round/ceil that optionally return a specified integral type
https://d.puremagic.com/issues/show_bug.cgi?id=12547 Summary: floor/round/ceil that optionally return a specified integral type Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2014-04-08 12:40:20 PDT --- With a small counting I've seen that in my code I have often to cast the result of the functions floor/round/ceil to integral values, like: cast(ubyte)round(x) cast(int)floor(y) But I prefer to avoid casts in my code. So I suggest to modify them (or to add new small functions) in Phobos that accept a template argument to specify the result integer type: round!ubyte(x) floor!int(y) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6586] feqrel for const values too
https://d.puremagic.com/issues/show_bug.cgi?id=6586
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #3 from hst...@quickfur.ath.cx 2014-04-08 13:23:49 PDT ---
Tested on git HEAD: the original code now compiles, although I did find a
different related failing case:
==Code:==
import std.math, std.stdio;
void main() {
const(double) a=1.0, b=2.0;
writeln(feqrel(a, b));
}
==Compile:==
/usr/src/d/phobos/std/math.d(5394): Error: cannot modify const expression diff
test.d(4): Error: template instance std.math.feqrel!(const(double)) error
instantiating
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12549] New: Immutable can't be casted when using nested pointers
https://d.puremagic.com/issues/show_bug.cgi?id=12549 Summary: Immutable can't be casted when using nested pointers Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jbin...@gmail.com --- Comment #0 from Jeroen Bollen jbin...@gmail.com 2014-04-08 14:12:22 PDT --- Created an attachment (id=1343) example file When using nested pointers, DMD seems to not be able to realize immutable is also constant. It'll result in errors similar to: function app.test2 (const(char)** test2) is not callable using argument types (immutable(char)**) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12549] Immutable can't be casted when using nested pointers
https://d.puremagic.com/issues/show_bug.cgi?id=12549 --- Comment #2 from Jeroen Bollen jbin...@gmail.com 2014-04-08 14:29:05 PDT --- (In reply to comment #1) Likely dupe of https://d.puremagic.com/issues/show_bug.cgi?id=4251. See the comment http://d.puremagic.com/issues/show_bug.cgi?id=4251#c9. That issue dates from 2 years ago, and it is marked as resolved, while this bug still occurs in the head and latest version (2.065) of DMD. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12549] Immutable can't be casted when using nested pointers
https://d.puremagic.com/issues/show_bug.cgi?id=12549 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-04-08 23:24:15 CEST --- Likely dupe of https://d.puremagic.com/issues/show_bug.cgi?id=4251. See the comment http://d.puremagic.com/issues/show_bug.cgi?id=4251#c9. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable(T)[] implicitly casts to ref const(T)[]
https://d.puremagic.com/issues/show_bug.cgi?id=4251 Jeroen Bollen jbin...@gmail.com changed: What|Removed |Added CC||jbin...@gmail.com --- Comment #23 from Jeroen Bollen jbin...@gmail.com 2014-04-08 14:39:44 PDT --- *** Issue 12549 has been marked as a duplicate of this issue. *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12549] Immutable can't be casted when using nested pointers
https://d.puremagic.com/issues/show_bug.cgi?id=12549 --- Comment #3 from Jeroen Bollen jbin...@gmail.com 2014-04-08 14:31:24 PDT --- Oh I see what you meant now. But when changing a pointer you should only allow it to point at what its type tells it to, a constant character in this case! That on its own is a bug. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12550] New: Deprecate -noboundscheck and replace with more useful -boundscheck= option
https://d.puremagic.com/issues/show_bug.cgi?id=12550 Summary: Deprecate -noboundscheck and replace with more useful -boundscheck= option Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: e...@gnuk.net --- Comment #0 from Brad Anderson e...@gnuk.net 2014-04-08 14:47:38 PDT --- -noboundscheck should be deprecated and replaced with -boundscheck=all|safe|none for a couple of reasons. 1. What -noboundscheck actually does is confusing. Its purpose is to turn off bounds checking in @safe code (and all other code) which comes as a surprise to a lot of people. -release turns off bounds checking in non-@safe code (which also surprises some people) but leaves it on for @safe code. 2. There is currently no way to turn on bounds checking for release builds currently. 3. There is currently no way to turn off bounds checking for non-@safe code without pulling in everything -release does (or turning off bounds checking for @safe code too). If we want to take this one step further there should be command line options (both enabling and disabling) for every effect -release has and -release should just be an alias for specifying a set of those options. (Martin Krejcirik came up with the idea for -boundscheck=) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12549] Immutable can't be casted when using nested pointers
https://d.puremagic.com/issues/show_bug.cgi?id=12549 Jeroen Bollen jbin...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jeroen Bollen jbin...@gmail.com 2014-04-08 14:39:44 PDT --- I see now, the poiter pointing to an immutable type can be changed to point to a const (mutable) type. *** This issue has been marked as a duplicate of issue 4251 *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12550] Deprecate -noboundscheck and replace with more useful -boundscheck= option
https://d.puremagic.com/issues/show_bug.cgi?id=12550 Brad Anderson e...@gnuk.net changed: What|Removed |Added Severity|normal |enhancement -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12549] Immutable can't be casted when using nested pointers
https://d.puremagic.com/issues/show_bug.cgi?id=12549 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #5 from Kenji Hara k.hara...@gmail.com 2014-04-08 19:43:21 PDT --- This is an invalid issue, because of the issue 4251. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
