[Issue 8360] Destruction of uninitialized temporary struct with assert
http://d.puremagic.com/issues/show_bug.cgi?id=8360 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8360] Destruction of uninitialized temporary struct with assert
http://d.puremagic.com/issues/show_bug.cgi?id=8360 --- Comment #3 from github-bugzi...@puremagic.com 2013-10-05 00:16:51 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f2d4350dc3d00a454a9e1619484404da75bec7be fix Issue 8360 - Destruction of uninitialized temporary struct with assert https://github.com/D-Programming-Language/dmd/commit/10b704a7d6fe04b597b0c99e537be4960cba270f Merge pull request #2620 from 9rnsr/fix8360 Issue 8360 8361 - Destruction of uninitialized temporary struct with assert -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11151] Undetected overlapping initialization
http://d.puremagic.com/issues/show_bug.cgi?id=11151 --- Comment #2 from github-bugzi...@puremagic.com 2013-10-05 00:33:02 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/cd6102367906c0a76f4ad56375e8bdf653321e0b fix Issue 11151 - Undetected overlapping initialization -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11151] Undetected overlapping initialization
http://d.puremagic.com/issues/show_bug.cgi?id=11151 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11160] Bitfield compilation error with degenerate bitfields of length 32 64
http://d.puremagic.com/issues/show_bug.cgi?id=11160 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@klickverbot.at Resolution||FIXED --- Comment #6 from David Nadlinger c...@klickverbot.at 2013-10-05 08:18:03 PDT --- https://github.com/D-Programming-Language/phobos/pull/1613 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8474] bitfields doesn't work with 32 bit fields
http://d.puremagic.com/issues/show_bug.cgi?id=8474 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||c...@klickverbot.at Resolution||FIXED --- Comment #4 from David Nadlinger c...@klickverbot.at 2013-10-05 08:18:20 PDT --- https://github.com/D-Programming-Language/phobos/pull/1613 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5942] Bitfields are overwritten erroneously
http://d.puremagic.com/issues/show_bug.cgi?id=5942 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||c...@klickverbot.at Resolution||FIXED --- Comment #2 from David Nadlinger c...@klickverbot.at 2013-10-05 08:17:46 PDT --- https://github.com/D-Programming-Language/phobos/pull/1613 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9066] Add constructor inheritance feature
http://d.puremagic.com/issues/show_bug.cgi?id=9066 --- Comment #9 from Martin Nowak c...@dawg.eu 2013-10-05 09:01:17 PDT --- (In reply to comment #8) Your example wouldn't compile. You can't default construct a class that defines a non-default constructor even though we do have implicit constructor inheritance. The rule here is very simple, if you define a constructor none is inherited. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5520] bitfieldsOn
http://d.puremagic.com/issues/show_bug.cgi?id=5520 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #3 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-05 09:24:46 PDT --- He seems to have been referring to pull requests: 1045, 719, 734 and 740 (all closed unmerged.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3753] ICE(eh.c): Related to exception handling and alloca.
http://d.puremagic.com/issues/show_bug.cgi?id=3753 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Version|2.039 |D2 --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2013-10-05 11:12:20 PDT --- Turns assert into reasonable error message: https://github.com/D-Programming-Language/dmd/pull/2630 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11175] format prints null for all objects inheriting IUnknown
http://d.puremagic.com/issues/show_bug.cgi?id=11175 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-05 11:22:38 PDT --- I don't even see any special code handling in Phobos that would cause this. It seems like a compiler issue? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11176] New: array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176
Summary: array.ptr in @safe code
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from David Nadlinger c...@klickverbot.at 2013-10-05 11:29:36
PDT ---
The following program is @safe, yet reads from an invalid memory location:
---
@safe:
ubyte oops(ubyte[] b) {
return *b.ptr;
}
void main() {
oops(new ubyte[0]);
// - or -
auto b = new ubyte[42];
oops(b[$ .. $]);
}
---
To keep memory safety guarantees, we would at least have to make sure that the
element after the end of an array never belongs to a different, valid
allocation.
Brought up by Denis Shelomovskij in a discussion on GitHub.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11176] array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176 --- Comment #2 from David Nadlinger c...@klickverbot.at 2013-10-05 11:31:51 PDT --- The easiest fix would be to just disallow accessing the .ptr property in @safe code. There probably wouldn't be much reason to use it in the first place anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11176] array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176 --- Comment #1 from David Nadlinger c...@klickverbot.at 2013-10-05 11:30:23 PDT --- Forgot to mention: The above snippet compiles fine using DMD 2.064 Git (a35bd9e) on Linux x86_64. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9066] Add constructor inheritance feature
http://d.puremagic.com/issues/show_bug.cgi?id=9066
--- Comment #11 from Martin Nowak c...@dawg.eu 2013-10-05 11:49:56 PDT ---
(In reply to comment #10)
class A { this(int); this(double); }
// inherit the this(int) ctor
class B : A { this(string); alias super.this(int) this; }
-
This is more specific because you have to specify which constructor to inherit
by stating the parameter types. So you will save less typing over this(int a) {
super(a); }. It's still useful because you can reuse the default arguments and
the compiler will check for you that the parameter types match the base class.
No good idea for the syntax though. Maybe we can special case the alias syntax
as you used it in the example.
so maybe we should split this up into two enhancement requests
Makes sense.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9066] Add constructor inheritance feature
http://d.puremagic.com/issues/show_bug.cgi?id=9066
--- Comment #12 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-05
12:10:51 PDT ---
(In reply to comment #11)
This is more specific because you have to specify which constructor to inherit
by stating the parameter types. So you will save less typing over this(int a)
{
super(a); }.
I'm thinking it would save the binary size though (save on duplicated functions
that do nothing but forward arguments). Especially if you use a mixin template
to autogenerate these (for whatever reason).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6107] ICE(expression.c) when a non-template member named '__ctor' exists in a struct, and the constructor is attempted to be invoked.
http://d.puremagic.com/issues/show_bug.cgi?id=6107 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Platform|Other |All --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-05 12:15:20 PDT --- https://github.com/D-Programming-Language/dmd/pull/2631 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7806] ICE(gloop.c) iterating with idouble, when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=7806 --- Comment #5 from github-bugzi...@puremagic.com 2013-10-05 12:25:46 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ad9a300d9257105a1b8cab1443c2273d442ea04a fix Issue 7806 - ICE(gloop.c) iterating with idouble, when compiling with -O https://github.com/D-Programming-Language/dmd/commit/3e2986e09d14a90b8c0e20b15f92b586886b80d0 Merge pull request #2627 from WalterBright/fix7806 fix Issue 7806 - ICE(gloop.c) iterating with idouble, when compiling wit... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9190] Vector operations are not optimized for x86_64 architecture
http://d.puremagic.com/issues/show_bug.cgi?id=9190 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||safety0ff.b...@gmail.com Resolution||FIXED --- Comment #1 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-05 12:30:43 PDT --- https://github.com/D-Programming-Language/druntime/pull/471 (This was merged quite some time ago) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7806] ICE(gloop.c) iterating with idouble, when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=7806 --- Comment #6 from github-bugzi...@puremagic.com 2013-10-05 12:34:26 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/be315758f5342ad3fc3172c6f087e01cfe50ef07 Merge pull request #2627 from WalterBright/fix7806 fix Issue 7806 - ICE(gloop.c) iterating with idouble, when compiling wit... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11177] New: parameterized enum can't be typed
http://d.puremagic.com/issues/show_bug.cgi?id=11177
Summary: parameterized enum can't be typed
Product: D
Version: D2
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 2013-10-05 13:53:34 PDT ---
The new parameterized/template enum can't be typed.
//
enum int a= 5; //OK, a is an enum of type int
enum b(T) = 5; //OK, b is a template enum is of type infered
template c(T){enum int c = 5;}//OK, c is a template enum is of type int
enum int d(T) = 5; //???
//
main.d(d): Error: semicolon expected following function declaration
main.d(d): Error: Declaration expected, not '='
I'm not sure what the rules of DIP 42 state on this, but it seems strange this
doesn't work.
I think dmd is getting confused by into thinking I'm declaring a function, but
the = and enum should mean there is no ambiguity here, and it should be
accepted. I think.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11177] parameterized enum can't be typed
http://d.puremagic.com/issues/show_bug.cgi?id=11177 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-05 16:19:42 PDT --- I think there is a pull for this: https://github.com/D-Programming-Language/dmd/pull/2467 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11178] New: Class may implement same interface multiple times with different interface pointers, breaking (a is b) semantics
http://d.puremagic.com/issues/show_bug.cgi?id=11178 Summary: Class may implement same interface multiple times with different interface pointers, breaking (a is b) semantics Product: D Version: D1 D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: default_357-l...@yahoo.de --- Comment #0 from FeepingCreature default_357-l...@yahoo.de 2013-10-05 16:27:12 PDT --- Consider https://gist.github.com/6847299 . The errant behavior goes away if you remove the I2 inheritance from C2, indicating that C2 implements I2 _twice_ with different interface pointers. This leads to hilariously hard-to-find errors, since one generally assumes that casting two objects to the same interface makes them is-comparable if they're the same object. The second I2 in C2 should either be made illegal or silently ignored. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11176] array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2013-10-05 17:24:56 PDT --- An interesting side note to marking .ptr on arrays as unsafe would be that it would make it kind of pointless to mark a lot of C functions as @trusted like some folks have been trying to do in druntime (and incorrectly in some cases - e.g. bug# 11168), since then the function making the call would likely have to be marked as @trusted or @system quite often when calling C functions, as many C functions take arrays. And many that don't take arrays still take pointers of another kind, and taking the address of something is @system, so it makes me wonder if we should just not mark any C functions as anything but @system. It's already arguably bad to mark them as @trusted when we don't have their source code, and when you pretty much can't call them from @safe code anyway, it becomes rather pointless to try and mark them as @trusted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11176] array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176 --- Comment #4 from David Nadlinger c...@klickverbot.at 2013-10-05 17:29:59 PDT --- @J(In reply to comment #3) An interesting side note to marking .ptr on arrays as unsafe would be that it would make it kind of pointless to mark a lot of C functions as @trusted I think you are missing something here: A C function taking an array by pointer and length or a pointer to a zero-terminated array can never be @trusted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11176] array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176 --- Comment #5 from Jonathan M Davis jmdavisp...@gmx.com 2013-10-05 18:02:00 PDT --- I think you are missing something here: A C function taking an array by pointer and length or a pointer to a zero-terminated array can never be @trusted. Ah, that would be true. So, regardless of ptr, it's a problem. Though with druntime using @trusted: on whole modules in some places, I find it hard to believe that we're not screwing this up in several places. And with so many C functions taking pointers of one variety of another (combined with the fact that we don't have the actual source code for C functions normally), I'd be tempted to argue that marking C functions with @trusted should simply not be done under normal circumstances. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11176] array.ptr in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11176 --- Comment #6 from David Nadlinger c...@klickverbot.at 2013-10-05 18:37:22 PDT --- (In reply to comment #5) And with so many C functions taking pointers of one variety of another (combined with the fact that we don't have the actual source code for C functions normally), I'd be tempted to argue that marking C functions with @trusted should simply not be done under normal circumstances. I invite you to take up this argument with the people who are working hard to make Phobos usable in @safe code. ;) Jokes aside, C functions that are @safe should be marked as such, otherwise this will just lead to client code being marked as @trusted. And this not only shifts the problem, but as the expected fan-in of a druntime declaration is larger than one, makes the problem *worse* because now that difficult decision has to be made in several places instead of just one. I agree that marking functions as trusted (external or not) comes with a high potential for mistakes, but I'd argue that the best way to avoid making them is to help with reviewing the related pull requests (and the existing code once new pitfalls such as the reentrancy issue are discovered). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6720] ICE(cod1.c) casting return of void function to bool
http://d.puremagic.com/issues/show_bug.cgi?id=6720 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-10-05 18:51:47 PDT --- https://github.com/D-Programming-Language/dmd/pull/2632 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4611] stack overflow or ICE(cgcod.c) when static array of structs exceeds 16MB limit
http://d.puremagic.com/issues/show_bug.cgi?id=4611 --- Comment #4 from github-bugzi...@puremagic.com 2013-10-05 19:15:09 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/53645e4508880df0bf6ce0fd78c5596e075dddb4 fix Issue 4611 - stack overflow or ICE(cgcod.c) when static array of structs exceeds 16MB limit https://github.com/D-Programming-Language/dmd/commit/3e87ccdd4db2e4581b799af728ed36f58dcd29c1 Merge pull request #2624 from WalterBright/fix4611 fix Issue 4611 - stack overflow or ICE(cgcod.c) when static array of str... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7524] #line __LINE__ doesn't parse on D2.020 and later
http://d.puremagic.com/issues/show_bug.cgi?id=7524 --- Comment #2 from github-bugzi...@puremagic.com 2013-10-05 19:17:09 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/456890cf858d9e62efc3bef2316c0ee2699b962d fix Issue 7524 - #line __LINE__ doesn't parse on D2.020 and later https://github.com/D-Programming-Language/dmd/commit/792382a068d8a958a736f10e7bb091c1715576eb Merge pull request #2621 from WalterBright/fix7524 fix Issue 7524 - #line __LINE__ doesn't parse on D2.020 and later -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7524] D1: #line __LINE__ doesn't parse
http://d.puremagic.com/issues/show_bug.cgi?id=7524 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Version|D1 D2 |D1 Summary|#line __LINE__ doesn't |D1: #line __LINE__ doesn't |parse on D2.020 and later |parse --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-05 19:50:43 PDT --- Fixed for D2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7524] D1: #line __LINE__ doesn't parse
http://d.puremagic.com/issues/show_bug.cgi?id=7524 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2013-10-05 19:56:37 PDT --- Although __LINE__ isn't supported in D1, it doesn't crash as reported here with 1.077. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4611] stack overflow or ICE(cgcod.c) when static array of structs exceeds 16MB limit
http://d.puremagic.com/issues/show_bug.cgi?id=4611 --- Comment #5 from github-bugzi...@puremagic.com 2013-10-05 20:08:46 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5e9152194f589d2e3556d87e99edb9865bdab6dd Merge pull request #2624 from WalterBright/fix4611 fix Issue 4611 - stack overflow or ICE(cgcod.c) when static array of str... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11174] Both AF_PACKET and SO_BINDTODEVICE undefined
http://d.puremagic.com/issues/show_bug.cgi?id=11174 --- Comment #1 from daniel...@bigpond.com 2013-10-05 20:08:23 PDT --- (In reply to comment #0) AF_PACKET and SO_BINDTODEVICE are both undefined in any/all of the socket modules. Although they are not standard, they should still be available on platforms that support them. Their definitions (at least on my platform) are the following: AF_PACKET = 17; SO_BINDTODEVICE = 25; These constants can be found (at least in my machine), at the following location: `/usr/include/bits/socket.h`. Also, all of the `/usr/include/linux/if_ether.h` constants would be very useful for this also. Such as (in my case) ETH_P_ALL. Offhand reference: http://www.scs.stanford.edu/histar/src/uinc/linux/if_ether.h It almost feels like we just need to have a way of automatically merging these constants into the appropriate D files... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4611] stack overflow or ICE(cgcod.c) when static array of structs exceeds 16MB limit
http://d.puremagic.com/issues/show_bug.cgi?id=4611 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6774] ICE(glue.c) totym gagged forward reference error
http://d.puremagic.com/issues/show_bug.cgi?id=6774
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||bugzi...@digitalmars.com
Resolution||WORKSFORME
--- Comment #8 from Walter Bright bugzi...@digitalmars.com 2013-10-05
20:26:52 PDT ---
(In reply to comment #7)
Reduced test case for comment 5:
void foo(T)(ref immutable(T) data) {}
void test6774() {
immutable a = 2.0f;
foo!(float)(a);
}
This compiles without error on 2.064 head.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6799] ICE(type.c) involving AAs and pointers to structs
http://d.puremagic.com/issues/show_bug.cgi?id=6799 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com OS/Version|Windows |All --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-05 21:09:10 PDT --- https://github.com/D-Programming-Language/dmd/pull/2633 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7156] ICE(go.c): with 199 or 200 repeated integer increments, only with -O
http://d.puremagic.com/issues/show_bug.cgi?id=7156 --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-05 22:49:59 PDT --- https://github.com/D-Programming-Language/dmd/pull/2634 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7169] [CTFE] Assertion failure with inner struct
http://d.puremagic.com/issues/show_bug.cgi?id=7169
--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-05
22:53:15 PDT ---
(In reply to comment #0)
struct Struct(T){
T t;
}
void func(T)(T t){
Struct!T s;
s.t = t;
}
static assert({
struct InnerStruct{
void func(){}
}
func(InnerStruct());
return true;
}());
void main(){}
This code doesn't work.
It produces a correct error message:
test.d(6): Error: delegate test.__lambda4 is a nested function and cannot be
accessed from test.func!(InnerStruct).func
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
