[Issue 8816] New: It should be illegal for enums to declare members named init, max, or min
http://d.puremagic.com/issues/show_bug.cgi?id=8816
Summary: It should be illegal for enums to declare members
named init, max, or min
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-13 23:57:05
PDT ---
TDPL (p.275) specifically allows for enums to declare members named min, max,
and init and then immediately tells you that it's a dumb idea to do so.
Allowing it is bound to break generic code, since it allows you to do nonsense
like
enum MyEnum : int {max, min, init}
completely breaking any guarantees about what the mean. And note this fun
situation:
enum MyEnum : int { a, b, c, init }
void main()
{
MyEnum e;
assert(e == MyEnum.a);
assert(MyEnum.init == MyEnum.a);
}
The first assertion passes and the second fails, meaning that the declartion of
init has effectively hidden the real init. I'd strongly argue that allowing the
overloading init, min, and max should be disallowed. Allowing it gains us
nothing and just causes bugs.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8817] New: Symbols named init should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=8817
Summary: Symbols named init should be illegal
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 00:04:46
PDT ---
The fact that the compiler currently allows any symbols to be named init just
causes problems. For instance, take this program:
struct S
{
int i = 2;
this(int j)
{
assert(i == 2);
i = j;
}
@property static init()
{
return S(5);
}
}
void main()
{
assert(S.init == S(2));
}
The assertion in main fails, while the assertion in the constructor succeeds.
That means that it's failing to actually override the init property for S
(which is good), but now the init property for S is inaccessible. This is
dangerous and will break all kinds of code. This sort of thing should just be
disallowed. It gains us nothing and just causes problems. Similarly, this code
struct S
{
int i = 2;
this(int j)
{
assert(i == 2);
i = j;
}
@property S init()
{
return S(5);
}
}
void main()
{
assert(S.init == S(2));
}
results in this compilation error:
q.d(19): Error: need 'this' for init type @property S()
So, again, it makes it impossible to access the type's init property.
For some reason, TDPL (p. 275) specifically permits enums to declare min, max,
and init properties, though it _does_ tell you that it's a bad idea to do so.
So, if that's to be permitted, init would still have to be allowed there, but
I'd strongly argue that that should be changed. And note that just like with
structs, it causes weird issues:
enum MyEnum : int { a, b, c, init }
void main()
{
MyEnum e;
assert(e == MyEnum.a);
assert(MyEnum.init == MyEnum.a);
}
The first assertion passes but the second fails, meaning that once again, you
can't get at the init property of the type anymore. Sure, declaring init as the
first value fixes that, but init would be the first value anyway if init
weren't explicitly declared. See issue# 8816.
The only situation where explicitly declaring init might make some sense would
be to @disable it, but the syntax for disabling init is @disable this(); and
not anything directly involving init. You can try and declare
struct S
{
int i;
@disable static S init;
}
void main()
{
S s;
}
but it compiles just fine.
At minimum, I would strongly argue that any and all symbols which could
conflict with the actual init property for a type should be made illegal. There
are a few cases where it may not cause problems (e.g. a local variable), but
I'd argue that it would be cleaner to just disallow those as well. If need be,
maybe init should become a keyword. Certainly, the current situation just
permits bugs and the ability to declare symbols named init which conflict with
the actual init property for a type needs to be eliminated.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8816] It should be illegal for enums to declare members named init, max, or min
http://d.puremagic.com/issues/show_bug.cgi?id=8816 --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 00:05:18 PDT --- See also issue# 8817. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8816] It should be illegal for enums to declare members named init, max, or min
http://d.puremagic.com/issues/show_bug.cgi?id=8816 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-14 09:36:24 CEST --- For what it's worth, I agree that it's nonsensical to even allow this. It's just inviting catastrophe. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8817] Symbols named init should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=8817 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-14 09:38:30 CEST --- This actually happens to be a problem in druntime's TypeInfo classes because they have a property called init. A lot of code currently relies on that 'overload' of the init symbol. https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L75 That comment has been there for eons. What do we do about it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8817] Symbols named init should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=8817 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 00:48:24 PDT --- That comment has been there for eons. What do we do about it? Create a function with the correct name (whatever that is - initialize?) and mark the old one as scheduled for deprecation making sure that we put an appropriate note in the changelog (in red if we think that it's major enough - I don't know how much code really uses TypeInfo, let alone TypeInfo.init() though). Then we deprecate it. It'll probably have to stick around as deprecated for a while to help the transition, but after that, we remove it, and it won't cause an issues any longer. Unfortunately, it wouldn't surprise me if there are plenty of types out there with an init function (std.file.DirEntry used to have one), but IMHO it's just fundamentally broken to allow that given how it conflicts with the actual init property. And I think that this is a case where it's worth breaking code if we have to (but that makes it that much more critical that we make the changes necessary for this sooner rather than later). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8809] Cannot statically bind to base class method overridden by derived class
http://d.puremagic.com/issues/show_bug.cgi?id=8809 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-10-14 03:02:36 PDT --- https://github.com/D-Programming-Language/dmd/pull/1181 And, this is also a problem in website. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8818] New: CTFE fails to compare strings correctly
http://d.puremagic.com/issues/show_bug.cgi?id=8818
Summary: CTFE fails to compare strings correctly
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: CTFE
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2012-10-14 06:16:27
PDT ---
Compiling with current version from github:
bool test()
{
string op1 = aa;
string op2 = b;
assert(b = aa);
assert(op2 = op1);
return true;
}
pragma(msg,test());
void main()
{
}
produces:
test.d(7): Error: assert(op2 = op1) failed
test.d(11):called from here: test()
test()
This does not happen with dmd 2.060. The regression was probably introduced
with this commit:
SHA-1: f3ee71f1f422fd0ee8863109469f4065a8305b5f
* Merge pull request #1114 from donc/ctfe8644_arrayliteralcmp
Fix bug 8644 - CTFE doesn't support string , on array literals
and is caused by ctfeRawCmp in interpret.c changing the semantics of the
comparison, because it compares the length of arrays before looking at the
contents.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8792] std.algorithm.joiner doesn't return a proper forward range
http://d.puremagic.com/issues/show_bug.cgi?id=8792 --- Comment #3 from github-bugzi...@puremagic.com 2012-10-14 08:28:15 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5a0c67f08553c05c532fe3c433e3bb944d8aa6dd Expanded test for issue# 8792. https://github.com/D-Programming-Language/phobos/commit/5037dd00bd66ee195da3b95dd7a5baa99f451106 Merge pull request #866 from jmdavis/tests Expanded test for issue# 8792. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8809] Cannot statically bind to base class method overridden by derived class
http://d.puremagic.com/issues/show_bug.cgi?id=8809 --- Comment #2 from github-bugzi...@puremagic.com 2012-10-14 08:31:12 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/946692fbad211e84207d41da392a1f60aac9fb65 Add documentation for issue 8809 This language feature has not been clearly documented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8819] New: void static array should have init built-in propert
http://d.puremagic.com/issues/show_bug.cgi?id=8819
Summary: void static array should have init built-in propert
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-10-14 09:04:24 PDT ---
Following code doesn't work with current dmd (2.060).
void main()
{
alias void[1] T;
auto vsa = T.init;
}
output:
test.d(4): Error: void does not have a default initializer
I think this is unnecessary restriction and almost a bug.
An element of void[1] should have '0' as a default initializer.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8820] New: Array initialization generates garbage
http://d.puremagic.com/issues/show_bug.cgi?id=8820
Summary: Array initialization generates garbage
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: malteskaru...@web.de
--- Comment #0 from Malte Skarupke malteskaru...@web.de 2012-10-14 11:23:55
PDT ---
Array initialization currently generates garbage that needs to be collected by
the GC.
{
int[5] a = [1, 2, 3, 4, 5]; // generates garbage
}
{
int[5] a;
foreach (i; 0 .. 5)
{
a[i] = i + 1;
} // same thing, but no garbage. everything is on the stack
}
Creating an array on the stack should be a trivial and fast operation. Yet
stepping through the disassembly of that first line reveals a lot of overhead.
But for now all I want fixed is that the first line does not generate garbage.
The reason for why it generates garbage is that it allocates on the heap, then
memcpys over to the stack, and never cleans up the memory on the heap.
It should obviously initialize directly on the stack.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8820] Array initialization generates garbage
http://d.puremagic.com/issues/show_bug.cgi?id=8820 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||DUPLICATE --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 11:36:34 PDT --- *** This issue has been marked as a duplicate of issue 2356 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||malteskaru...@web.de --- Comment #11 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 11:36:34 PDT --- *** Issue 8820 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8820] Array initialization generates garbage
http://d.puremagic.com/issues/show_bug.cgi?id=8820 --- Comment #3 from Malte Skarupke malteskaru...@web.de 2012-10-14 12:18:14 PDT --- (In reply to comment #2) This is a long-standing, known issue. As a side note, it would be better to say that it allocates memory when it shouldn't rather than talking about generating garbage. That tends to imply that it generates garbage data (which it doesn't), giving the wrong impression about what you're talking about. All GC heap memory must naturally be garbage collected, so the issue is that it's allocated in the first place rather than the fact that it needs to be collected later. Ah sorry for not seeing the other issue. I searched for array initialization, but didn't come across that one. And yeah, I can see there being issues with the double meaning of garbage in terms of the garbage collector and garbage in terms of garbage data. I'll use different terminology in the future. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8821] New: countUntil chokes on reference ranges
http://d.puremagic.com/issues/show_bug.cgi?id=8821
Summary: countUntil chokes on reference ranges
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-10-14 13:43:47 PDT ---
Example:
//---
import std.algorithm;
import std.stdio;
import std.array;
struct Forward
{
static struct P
{
string s;
}
P* _p;
this(string si)
{
_p = new P();
_p.s = si;
}
@property dchar front()
{
return _p.s.front;
}
void popFront()
{
_p.s.popFront();
}
bool empty()
{
return _p.s.empty;
}
}
void main()
{
auto s = Forward(abc);
auto s1 = Forward(ac);
s.countUntil(s1).writeln();
}
//---
Produces 1.
ROOT CAUSE ANALYSIS: The problem is startsWith, which will consume both its
input (both haystack and needle). Here, the first call to start with will
consume the a of both abc and ac. countUntil will the pop the b off of
bc, and finally, call startsWith on c and c.
Recommend saving ranges before calling startsWith (if both are ranges), but a
more efficient solution could be found.
Assigning to self.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8821] countUntil chokes on reference ranges
http://d.puremagic.com/issues/show_bug.cgi?id=8821 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2012-10-14 13:45:39 PDT --- (In reply to comment #0) Assigning to self. Assigning to self. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4669] Unit tests do not work in libraries compiled by dmd with -lib
http://d.puremagic.com/issues/show_bug.cgi?id=4669 PhilLavoie maidenp...@hotmail.com changed: What|Removed |Added CC||maidenp...@hotmail.com OS/Version|Linux |Windows --- Comment #4 from PhilLavoie maidenp...@hotmail.com 2012-10-14 14:57:54 PDT --- Yeah, I also confirm this issue on Windows. Since unit testing plays an important part in software construction, I hope that it gets the attention it deserves and gets fixed soon :). Love D 4 Life. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8820] Array initialization generates garbage
http://d.puremagic.com/issues/show_bug.cgi?id=8820 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 16:09:07 PDT --- Ah sorry for not seeing the other issue. I searched for array initialization, but didn't come across that one. Not a problem. It happens all the time. All it takes is someone wording things differently from how you think of the problem, and you won't find the issue. Just make sure that you put in a good faith effort to find an existing bug report before reporting it (as it sounds like you did). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8791] Optlink fails when reading PATH variable and -g is used
http://d.puremagic.com/issues/show_bug.cgi?id=8791 webwra...@fastmail.fm changed: What|Removed |Added CC||webwra...@fastmail.fm --- Comment #3 from webwra...@fastmail.fm 2012-10-14 16:15:22 PDT --- Appears to work only if PATH is set to something that has absolutely no spaces in it, regardless of speech marks or quotes -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8791] Optlink fails when reading PATH variable and -g is used
http://d.puremagic.com/issues/show_bug.cgi?id=8791 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-14 16:38:52 PDT --- (In reply to comment #3) Appears to work only if PATH is set to something that has absolutely no spaces in it, regardless of speech marks or quotes The first example doesn't have any spaces in it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5860] optlink borken for paths with + (plus) in PATH
http://d.puremagic.com/issues/show_bug.cgi?id=5860 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-14 18:01:40 PDT --- *** This issue has been marked as a duplicate of issue 4831 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8791] Optlink fails when reading PATH variable and -g is used
http://d.puremagic.com/issues/show_bug.cgi?id=8791 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-14 18:01:25 PDT --- *** This issue has been marked as a duplicate of issue 4831 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4831] Optlink failed to parse PATH env variable with -g option
http://d.puremagic.com/issues/show_bug.cgi?id=4831 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||s...@extrawurst.org --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-14 18:01:40 PDT --- *** Issue 5860 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4831] Optlink failed to parse PATH env variable with -g option
http://d.puremagic.com/issues/show_bug.cgi?id=4831 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-14 18:01:26 PDT --- *** Issue 8791 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6649] core.sys.posix.sys.ioctl
http://d.puremagic.com/issues/show_bug.cgi?id=6649 --- Comment #2 from github-bugzi...@puremagic.com 2012-10-14 19:16:10 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/5e1cefadea362203beb59e1ce44ad20f7d80ba46 Fix issue #6649 (partially) - add core.sys.posix.sys.ioctl header module for Linux. https://github.com/D-Programming-Language/druntime/commit/534c114d260d41dd518336232c3fa68ef13bdffc Merge pull request #318 from alexrp/ioctl-posix Fix issue #6649 (partially) - add core.sys.posix.sys.ioctl header module for Linux. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5593] Add dladdr to druntime for linux/FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=5593 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alex R�nne Petersen a...@lycus.org 2012-10-15 04:17:54 CEST --- Done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444 --- Comment #9 from github-bugzi...@puremagic.com 2012-10-14 19:19:00 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/a77c82772e7e7b2d1d863b1fb56b614b9d4bc6a1 fix Issue 7444 - Require [] for array copies too https://github.com/D-Programming-Language/druntime/commit/be3a7fa1bc726b453203c058ff2fa8c81dcfcab1 Merge pull request #314 from 9rnsr/fix7444 Supplemental changes for Issue 7444 - Require [] for array copies too -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7112] Add function in core.sys.posix.signal
http://d.puremagic.com/issues/show_bug.cgi?id=7112 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7112] Add function in core.sys.posix.signal
http://d.puremagic.com/issues/show_bug.cgi?id=7112 --- Comment #3 from github-bugzi...@puremagic.com 2012-10-14 19:18:34 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/1d21ce334f9481ae9eaed190f78793944a0ca8ea Fix issue #7112 - add core.sys.linux.sys.signalfd module. https://github.com/D-Programming-Language/druntime/commit/168c1ec0b77368ee9fb881125e0684ca3e101ec7 Merge pull request #315 from alexrp/signalfd-linux Fix issue #7112 - add core.sys.linux.sys.signalfd module. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5593] Add dladdr to druntime for linux/FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=5593 --- Comment #5 from github-bugzi...@puremagic.com 2012-10-14 19:30:20 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/a2c549423c80413b73a78fbd5f60b078b99175b2 Fix issue #5593 - add dladdr, dlvsym, and Dl_info to core.sys.posix.dlfcn. https://github.com/D-Programming-Language/druntime/commit/ada94ebe2eb4f855945290d49c4a79d558827710 Merge pull request #324 from alexrp/dladdr Fix issue #5593 - add dladdr, dlvsym, and Dl_info to core.sys.posix.dlfcn. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8822] New: Usiing qualified delegate type in template argument causes parser error.
http://d.puremagic.com/issues/show_bug.cgi?id=8822
Summary: Usiing qualified delegate type in template argument
causes parser error.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
Depends on: 4838
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-10-14 20:38:19 PDT ---
Spin out issue from bug 8813.
This is a rest of bug 4838.
void main()
{
struct S { void foo() const {} }
S s;
void delegate() const dg = s.foo; // OK
void foo(void delegate() const dg){}// OK
struct Foo(T) {}
alias Foo!(void delegate() const) X;// NG
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8813] Cannot define delegate with const/immutable/shared/inout attributes
http://d.puremagic.com/issues/show_bug.cgi?id=8813
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-10-14 20:50:28 PDT ---
(In reply to comment #0)
This code doesn't work:
---
void main()
{
auto dg = delegate() const { }; // NG
}
---
In current, the semantics about qualified nested function (==lambda literal) is
not defined in language spec. Compiler assumes that the frame pointer of nested
function is always mutable.
And, I do not know whether a cause is the same as this problem... This code
doesn't work, too.
---
import std.traits;
void main()
{
static assert(is(FunctionTypeOf!(void delegate() const) == const)); // NG
alias void delegate() const DG; // OK
static assert(is(FunctionTypeOf!DG == const)); // OK
}
---
This is a parser bug and a rest of issue 4838.
I've separated it to bug 8822.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
