[Issue 9265] Nullable fixed-sized array wrapper
http://d.puremagic.com/issues/show_bug.cgi?id=9265 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2013-02-04 22:57:48 PST --- (In reply to comment #0) > std.typecons.Nullable and std.typecons.NullableRef contain enforce() that > throws and kills inlining. FYI: I submitted a pull that changes those enforces to logic errors (asserts): https://github.com/D-Programming-Language/phobos/pull/1103 This should allow the code to inline. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8837] BigInt needs better operator template constraints
http://d.puremagic.com/issues/show_bug.cgi?id=8837 Andrej Mitrovic 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 8837] BigInt needs better operator template constraints
http://d.puremagic.com/issues/show_bug.cgi?id=8837 --- Comment #2 from github-bugzi...@puremagic.com 2013-02-04 20:15:12 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7c616db71a5f7b1568a46a0044dcb636b2bc7ee6 Fixes Issue 8837 - BigInt needs better operator constraints. https://github.com/D-Programming-Language/phobos/commit/295ff3b64d9e58d347ff898402e066e39f9174ea Merge pull request #1112 from AndrejMitrovic/Fix8837 Issue 8837 - BigInt needs better operator constraints. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3915] typeid not getting type of offsetof standard property
http://d.puremagic.com/issues/show_bug.cgi?id=3915 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic 2013-02-04 18:48:05 PST --- Works in 2.061. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3785] std.random.uniform(bound, uint, uint)(uint.min, uint.max) fails.
http://d.puremagic.com/issues/show_bug.cgi?id=3785 Andrej Mitrovic changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic 2013-02-04 18:40:16 PST --- 2.039 fails with an integer divide by zero. 2.053+ seems to work fine. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3672] read-modify-write (rmw) operators must be disabled for shared
http://d.puremagic.com/issues/show_bug.cgi?id=3672 Andrej Mitrovic changed: What|Removed |Added CC||and...@erdani.com, ||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-02-04 18:26:54 PST --- CC'ing Andrei for update. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3434] +f(); should be an invalid statement.
http://d.puremagic.com/issues/show_bug.cgi?id=3434 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #2 from Andrej Mitrovic 2013-02-04 18:24:35 PST --- I don't see the reason for it either, closing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3019] std.typetuple: add some templates
http://d.puremagic.com/issues/show_bug.cgi?id=3019 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-02-04 18:21:39 PST --- staticMap, allSatisfy are now in std.traits. I don't know about the benefits of the other ones in the attachment, I haven't seen requests for them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2950] Switch for enum : string fails
http://d.puremagic.com/issues/show_bug.cgi?id=2950 --- Comment #5 from Andrej Mitrovic 2013-02-04 18:18:02 PST --- (In reply to comment #4) > http://d.puremagic.com/issues/show_bug.cgi?id=2950 Should have been: https://github.com/D-Programming-Language/dmd/pull/1358 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2929] Alias this when this is null
http://d.puremagic.com/issues/show_bug.cgi?id=2929 Andrej Mitrovic changed: What|Removed |Added Status|REOPENED|RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #3 from Andrej Mitrovic 2013-02-04 18:17:14 PST --- I don't understand this report. alias won't protect you from null references, keeping references non-null is the programmer's responsibility. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2864] intra-module use of deprecated should be allowed
http://d.puremagic.com/issues/show_bug.cgi?id=2864 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #4 from Andrej Mitrovic 2013-02-04 18:12:10 PST --- (In reply to comment #3) > > I think the right fix for that is for the compiler to not complain about > > deprecated symbol usage if the usage is in the same module the deprecated > > symbol is defined in. > > Is this really necessary? It sounds like it could be done using private > symbols and public deprecated symbols. Agreed. And I've heard no complains about this except in this ancient report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9112] Uniform construction for built-in types
http://d.puremagic.com/issues/show_bug.cgi?id=9112 Andrej Mitrovic changed: What|Removed |Added CC||and...@erdani.com --- Comment #22 from Andrej Mitrovic 2013-02-04 18:06:46 PST --- *** Issue 2600 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 2600] Nonuniform treatment of built-in types and user-defined types in value syntax
http://d.puremagic.com/issues/show_bug.cgi?id=2600 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #2 from Andrej Mitrovic 2013-02-04 18:06:46 PST --- Issue9112 has a pull request and more info. *** This issue has been marked as a duplicate of issue 9112 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1734] Inconsistent mixin behaviour
http://d.puremagic.com/issues/show_bug.cgi?id=1734 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #4 from Andrej Mitrovic 2013-02-04 18:01:08 PST --- Worst case scenario you can still use string mixins: string init() { return q{ a = 5; }; } void main() { int a; mixin(init); } So it's not all bad. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2257] Template value parameters behave like alias parameters
http://d.puremagic.com/issues/show_bug.cgi?id=2257 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Platform|x86 |All Resolution||WORKSFORME OS/Version|Windows |All --- Comment #8 from Andrej Mitrovic 2013-02-04 17:55:12 PST --- Fixed since a long time ago, tested as far back as 2.053. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2598] Alias declaration doesn't work for a tuple field
http://d.puremagic.com/issues/show_bug.cgi?id=2598 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic 2013-02-04 17:44:13 PST --- Works since 2.061. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2565] Should be able to use an inherited method as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=2565 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #6 from Andrej Mitrovic 2013-02-04 17:42:55 PST --- (In reply to comment #5) > but the means should be explicit. This could be implementable via a mixin template, similar to how forwarding constructors were proposed in Issue9066. A general-purpose template could be written which could be used via: mixin Forward!(BaseClass, "funcName"); And another template which uses it to fix this issue with: class Foo : public FooImpl, public IFoo { mixin ImplementInterface!(IFoo, FooImpl); // which expands to: mixin Forward!(FooImpl, "foo"); mixin Forward!(FooImpl, "bar"); // which expands to: override int foo() { return FooImpl.foo(); } override int bar() { return FooImpl.bar(); } } Internally it would iterate through all IFoo interface functions and find the matching implementations in FooImpl, and use `Forward` to mixin in a forwarding function. Or we would have language support. Anyway it should be doable as a library solution for the time being. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9451] Listing abstract functions in diagnostic should show full signature
http://d.puremagic.com/issues/show_bug.cgi?id=9451 Andrej Mitrovic changed: What|Removed |Added Keywords||pull AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-02-04 15:58:31 PST --- https://github.com/D-Programming-Language/dmd/pull/1620 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9451] New: Listing abstract functions in diagnostic should show full signature
http://d.puremagic.com/issues/show_bug.cgi?id=9451 Summary: Listing abstract functions in diagnostic should show full signature Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: diagnostic Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2013-02-04 15:28:35 PST --- class C { abstract void foo(int); abstract void foo(float); } class D : C { override void foo(int) { } } void main() { auto d = new D; } test.d(14): Error: cannot create instance of abstract class D test.d(14): Error: function foo is abstract This makes its difficult to know which overload of a function is not implemented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7576] linker error for structs with non-copyable fields
http://d.puremagic.com/issues/show_bug.cgi?id=7576 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic 2013-02-04 14:11:03 PST --- Fixed since 2.061. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7520] opDollar undocumented
http://d.puremagic.com/issues/show_bug.cgi?id=7520 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com See Also||http://d.puremagic.com/issu ||es/show_bug.cgi?id=3474 --- Comment #1 from Andrej Mitrovic 2013-02-04 14:14:17 PST --- The feature was implemented in Issue3474 by https://github.com/D-Programming-Language/dmd/pull/442 I suggest Don and/or Kenji get on this since they know exactly how opDollar works. Apparently it can be a template, but I know very little about this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7071] "final:" shouldn't affect variables
http://d.puremagic.com/issues/show_bug.cgi?id=7071 Andrej Mitrovic changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-02-04 14:06:55 PST --- *** Issue 7724 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 7724] 'final:' causes error if any variable declarations are placed between it and the end of its scope
http://d.puremagic.com/issues/show_bug.cgi?id=7724 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #18 from Andrej Mitrovic 2013-02-04 14:06:55 PST --- *** This issue has been marked as a duplicate of issue 7071 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8602] ICE(mtype.c) string mixin + auto return type + template tuple
http://d.puremagic.com/issues/show_bug.cgi?id=8602 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #5 from Andrej Mitrovic 2013-02-04 13:45:19 PST --- (In reply to comment #3) > Further reduced. > -- > template T8602(func...) if (func.length == 1) { } > > struct Bug8602 { > auto xx() { } > } > > T8602!(mixin("Bug8602.xx")) mm; The ICE is gone in git-head, now only gives: Error: T8602!(xx) is used as a type -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8641] Multiple errors on accessing undefined identifier
http://d.puremagic.com/issues/show_bug.cgi?id=8641 Andrej Mitrovic changed: What|Removed |Added Keywords|ice |diagnostic CC||andrej.mitrov...@gmail.com Summary|Segfault on accessing |Multiple errors on |undefined identifier|accessing undefined ||identifier --- Comment #1 from Andrej Mitrovic 2013-02-04 13:40:30 PST --- Not an ICE since 2.061, however the diagnostic prints out too many errors: test.d(5): Error: undefined identifier isMutable test.d(5): Error: undefined identifier isMutable test.d(5): Error: undefined identifier isMutable test.d(5): Error: undefined identifier isMutable test.d(13): Error: template instance test.MutableConst!(int, false) error instantiating -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8837] BigInt needs better operator template constraints
http://d.puremagic.com/issues/show_bug.cgi?id=8837 Andrej Mitrovic changed: What|Removed |Added Keywords|diagnostic |pull CC||andrej.mitrov...@gmail.com Platform|x86 |All AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com Summary|BigInt/boolean error|BigInt needs better |message |operator template ||constraints OS/Version|Windows |All --- Comment #1 from Andrej Mitrovic 2013-02-04 13:08:07 PST --- https://github.com/D-Programming-Language/phobos/pull/1112 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8869] std.typecons.Unique instance doesn't compile, needs std.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=8869 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #2 from Andrej Mitrovic 2013-02-04 12:48:24 PST --- Fixed since 2.060. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9050] compiler crash on return type inference
http://d.puremagic.com/issues/show_bug.cgi?id=9050 Andrej Mitrovic changed: What|Removed |Added Keywords|ice | CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-02-04 12:38:06 PST --- Test-case without requiring -unittest: struct A(T) {} struct B(T) { void f() { foo(A!int()); } } auto foo()(A!int base) pure { return B!int(); } auto l = foo(A!int()); void main() { } The crash is gone in 2.061 so this is no longer an ICE. Is the return type inference error expected? Otherwise close with WORKSFORME if this was only an ICE report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9033] Remove __thread from the language
http://d.puremagic.com/issues/show_bug.cgi?id=9033 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-02-04 12:32:13 PST --- https://github.com/D-Programming-Language/dmd/pull/1616 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9066] Implement constructor forwarding template
http://d.puremagic.com/issues/show_bug.cgi?id=9066 --- Comment #3 from Andrej Mitrovic 2013-02-04 12:00:13 PST --- There's a few problems: Default values aren't handled, and they could be initialized with a non-accessible private value. The parameter types could also be private types which might not be accessible. It would definitely be simpler to implement inheriting constructors, C++11 has them, described here: http://stackoverflow.com/questions/9979194/what-is-constructor-inheritance Perhaps we could implement something similar via: class C : B { alias super.this this; } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9067] Can't assign values from privately included modules to enums.
http://d.puremagic.com/issues/show_bug.cgi?id=9067 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #1 from Andrej Mitrovic 2013-02-04 11:25:50 PST --- And where is 'bar' defined? Anyway if I manually define the bar module with those identifiers both samples work. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7236] Protected class members in different file inaccessible
http://d.puremagic.com/issues/show_bug.cgi?id=7236 --- Comment #7 from Andrej Mitrovic 2013-02-04 11:16:08 PST --- (In reply to comment #6) > This is exactly the way it is designed to work. Accessibility is determined by > the 'this' pointer, not the function it is in. Perhaps, but it could be a future enhancement. I'm not sure about the pros vs cons, maybe encapsulation would break under this enhancement. The damage seems limited though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9447] iota should generate char intervals too
http://d.puremagic.com/issues/show_bug.cgi?id=9447 --- Comment #3 from Andrej Mitrovic 2013-02-04 10:57:34 PST --- (In reply to comment #2) > It is definitely _not_ the case that adding 1 to a wchar or dchar will > necessarily result in a valid value. In both of them, there's a block in the > middle which is invalid. Just like at the implementation of isValidDchar. Is this the only restriction though? If that's so, it should be easy to implement this feature with a single runtime check to verify the range doesn't go over the invalid block. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9127] Error on getting `stringof` on field with body-less interface type
http://d.puremagic.com/issues/show_bug.cgi?id=9127 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-02-04 10:55:47 PST --- This is true for any forward declaration: interface I; struct S; class C; enum ei = I.stringof; enum es = S.stringof; enum ec = C.stringof; test.d(3): Error: interface test.I is forward referenced when looking for 'stringof' test.d(7): Error: struct S is forward referenced test.d(5): Error: class test.C is forward referenced when looking for 'stringof' Note that Walter has stated before that .stringof is allowed to be overriden by the user, so this might have to be closed as invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9447] iota should generate char intervals too
http://d.puremagic.com/issues/show_bug.cgi?id=9447 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis 2013-02-04 10:48:33 PST --- It is definitely _not_ the case that adding 1 to a wchar or dchar will necessarily result in a valid value. In both of them, there's a block in the middle which is invalid. Just like at the implementation of isValidDchar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9447] iota should generate char intervals too
http://d.puremagic.com/issues/show_bug.cgi?id=9447 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-02-04 10:15:42 PST --- The reason I mentioned Unicode in Issue 8920 is because I'm unsure whether simply incrementing the integral value of a character will produce a valid character (valid in how the Unicode standard defines it). For ASCII 'a'--'z' it's likely not an issue, but I'm thinking about the case of wchars and dchars. E.g. we would probably have to use isValidDchar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9450] make assert an implicit "version (assert)"
http://d.puremagic.com/issues/show_bug.cgi?id=9450 Andrej Mitrovic changed: What|Removed |Added Keywords||pull AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-02-04 10:11:40 PST --- https://github.com/D-Programming-Language/dmd/pull/1614 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9450] make assert an implicit "version (assert)"
http://d.puremagic.com/issues/show_bug.cgi?id=9450 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com, ||k.hara...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-02-04 10:05:57 PST --- CC'ed Kenji. @Kenji: I think all that's required here is to return early in 'AssertExp::semantic' if 'global.params.release' is true, e.g.: Expression *AssertExp::semantic(Scope *sc) { if (global.params.release) { type = Type::tvoid; return this; } // ... } It seems to work for this simple case. Would this be ok? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9289] Deprecated language features should be warn too when errors are normally silented
http://d.puremagic.com/issues/show_bug.cgi?id=9289 --- Comment #21 from Leandro Lucarella 2013-02-04 08:34:16 PST --- BTW, Don, I see what you mean now, but that problem existed before making deprecations emit warnings by default (if you used -d). The default was only changed. I know that introduces some kind of regression in a sense because code will behave differently unless you use -de, but I think this is only a transitional problem, as again, only the default changed. If some deprecated feature gets too problematic, I agree with David that the best solution might be to just remove them, specially if they have been deprecated long ago... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9235] Template mixin doesn't allow to mixin non-conflicting overloads
http://d.puremagic.com/issues/show_bug.cgi?id=9235 --- Comment #3 from Maksim Zholudev 2013-02-04 08:12:40 PST --- Signature constraints are ignored also for structures: --- struct A { void foo(string s)() if(s == "a") {} } struct B { void foo(string s)() if(s == "b") {} } struct Foo { A a; B b; alias a.foo foo; alias b.foo foo; } void main() { Foo f; f.foo!"a"(); } --- test.d(16): Error: alias test.Foo.foo conflicts with alias test.Foo.foo at test.d(15) --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9442] typeid() doesn't work without `this.` for class fields
http://d.puremagic.com/issues/show_bug.cgi?id=9442 Andrej Mitrovic 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 9450] New: make assert an implicit "version (assert)"
http://d.puremagic.com/issues/show_bug.cgi?id=9450 Summary: make assert an implicit "version (assert)" Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-02-04 04:39:47 PST --- With the new conditional "version(assert)", we can write functions that are dedicated to being used with asserts, and have them only compiled in when there are actually asserts. The problem is that the assert itself is still compiled in, verified, then removed. Because of this, asserts that use code that is compiled in with asserts fails to compile. This forces the user to use a "version(assert) assert(foo());" semantic. Example: // void main() { //This works version(assert) assert(foo()); //But this doesn't assert(foo); //main.d(7) } version(assert) { bool foo() { return true; } } // rdmd -release main.d // main.d(7): Error: undefined identifier foo // I'd like the for assert to be enhanced to have the same semantics as if it was actually in a "version(assert)" block. It's the logical behavior for it anyways... For a real world example, I had this pull for std.container.Array: https://github.com/D-Programming-Language/phobos/pull/878/files It streamlined error checking with dedicated functions. I realized afterwards that the code does not compile in -release. I now have to either: - use "version(assert) assert(...);" - Copy paste/mixin a ton of code. IMO, both solutions are inferior to just having the assert being version'ed out. I can work around the problem, but it's one of those little things that makes everything smother when it works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9449] New: Segmentation fault in main()
http://d.puremagic.com/issues/show_bug.cgi?id=9449 Summary: Segmentation fault in main() Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: tbanelweb...@free.fr --- Comment #0 from tbanelweb...@free.fr 2013-02-04 03:51:35 PST --- This small code crashs. -- import core.simd; void main() { ubyte16 table[1]; } -- It crashes in: void[] *_memset128ii(void[] *p, void[] value, size_t count); It seems that a wrong "count" is passed in by the _Dmain() function. Details: DMD64 D Compiler v2.061 Linux Ubuntu x86_64 AMD Phenom II -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9289] Deprecated language features should be warn too when errors are normally silented
http://d.puremagic.com/issues/show_bug.cgi?id=9289 --- Comment #20 from Jonathan M Davis 2013-02-04 03:05:04 PST --- I agree with David on this one. If there's stuff here that really shouldn't be compiling, then lets finally remove it. Code shouldn't need to be checking whether deprecated features work or not. It shouldn't be trying to use them in the first place. And many of the currently deprecated language features have been deprecated for some time ande really should be outright removed. In general, warning for deprecations just works a lot better, so I'd hate to lose that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9289] Deprecated language features should be warn too when errors are normally silented
http://d.puremagic.com/issues/show_bug.cgi?id=9289 --- Comment #19 from Don 2013-02-04 02:57:16 PST --- Currently, is(typeof( )) NEVER, EVER produces an error message, no matter what is. You can put any kind of nonsense operation in there, and it will still compile, and return false. This change would create a horrific special case: is(typeof( )) never produces an error message, no matter what is, unless happened to be legal in an ancient version of DMD but is not legal in current DMD. This is a killer for generic code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9444] shell doesn't throw on error.
http://d.puremagic.com/issues/show_bug.cgi?id=9444 simendsjo changed: What|Removed |Added CC||simend...@gmail.com --- Comment #1 from simendsjo 2013-02-04 02:50:12 PST --- It should be noted that std.process will be deprecated (hopefully) soon. Here's the replacement: https://github.com/D-Programming-Language/phobos/pull/1100 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9448] New: CTFE ICE indexing block-initialized 2D static array
http://d.puremagic.com/issues/show_bug.cgi?id=9448 Summary: CTFE ICE indexing block-initialized 2D static array Product: D Version: D1 & D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2013-02-04 02:45:48 PST --- struct S9448 { int array[3][4]; } enum S9448 s9448 = S9448(67); int bug9448() { return s9448.array[1][2]; } static assert(bug9448()==67); dmd: ctfeexpr.c:1559: Expression* ctfeIndex(Loc, Type*, Expression*, uinteger_t): Assertion `e1->op == TOKarrayliteral' failed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9425] Static struct initializer fails to init array
http://d.puremagic.com/issues/show_bug.cgi?id=9425 --- Comment #3 from Don 2013-02-04 02:41:11 PST --- I did quite a lot of work (In reply to comment #2) > (In reply to comment #1) > > This is related to Bug2931. There's a dmd testcase for that in > > http://github.com/D-Programming-Language/dmd/blob/e7eff4deef0fb5ec9a89cee4716785832fc41fb9/test/runnable/test42.d#L3193 > > . The actual test case bug2931_2 conflicts with what I expected it to > > assert: > > Only the first element is initialized with the value, all other elements are > > assumed to be zero. > > This however contradicts dmd's behavior for the non-static case. > > For the one level block initializing of static array, current dmd generates > correct code. > > static int[3] x = 1; // block initializing > void main() { > import std.stdio; > writeln(x); // print [1, 1, 1]; > } > > It is from dmd0.98. > https://github.com/d-programming-language/dmd/commit/15d4546d07d5dedb7424677ae4dc0b18e57ef6da#L11R799 > > So, the test case for bug 2931 is wrong, IMO. I agree. Note that it behaves as expected in CTFE: --- struct S { int array[4]; } enum S s = S(67); int tain() { return s.array[2]; } static assert(tain()==67); Though I get a CTFE ICE if I change that to a 2D array :-(. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9289] Deprecated language features should be warn too when errors are normally silented
http://d.puremagic.com/issues/show_bug.cgi?id=9289 --- Comment #18 from Leandro Lucarella 2013-02-04 02:29:01 PST --- (In reply to comment #17) > (In reply to comment #16) > > This change would make deprecated features have an effect on ALL code. Even > > when not compiling with -d. > > That change is already in Git master. I'm pretty convinced that the best way > of > fixing any related issues is just to finally remove any deprecated language > features. Not only master, is in the last release. > > I am completely opposed to this change. It creates a special case which > > introduces new problems that are at least as bad as the old ones. > > What exactly do you regard as the special case here? Yeah, I think it was pretty clear that making deprecated features as warnings was, at some point, a breaking change, unless you use -de to achieve the old behaviour. I still have to review Don's example, because evidently I missed his point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 --- Comment #6 from Maxim Fomin 2013-02-04 01:41:01 PST --- (In reply to comment #4) > With git head and Windows 7 32bit PC, no segmentation fault occurs. > I think you need to report actual environment and compiler version. Still happens with git head. Neither original, nor reduced example segfaults at runtime on windows on 2.061, so the issue seems to be either linux bug or common one but fixed in 2.061 windows release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 --- Comment #5 from Maxim Fomin 2013-02-04 01:20:55 PST --- (In reply to comment #4) > With git head and Windows 7 32bit PC, no segmentation fault occurs. > I think you need to report actual environment and compiler version. I used linux64 and git head (actually it was 2-3 days old). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 --- Comment #4 from Kenji Hara 2013-02-04 01:16:56 PST --- With git head and Windows 7 32bit PC, no segmentation fault occurs. I think you need to report actual environment and compiler version. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9438] Strange RefCounted stack overflow
http://d.puremagic.com/issues/show_bug.cgi?id=9438 --- Comment #10 from Maxim Fomin 2013-02-04 01:11:11 PST --- (In reply to comment #9) > (In reply to comment #8) > > It really seems to be codegen bug. > > Thankyou for investigating this. As I said, it really is out of my league. Do > you know what the next step is for fixing this? Who we should forward it to? This does not work. Until somebody who knows dmd source faces the issue, the bug will not be fixed simply because there are too much problems and too few people. > We should really get this fixed. Stack corruption when an exception is thrown? > Nothing good can come out of this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 --- Comment #3 from Maxim Fomin 2013-02-04 00:55:34 PST --- Reduced: class S { void bar() { } } import core.stdc.stdio : printf; struct Function { int[] ai = [1,2,3]; } @property void meta(alias m)() { static Function md; printf("length = %d\n", md.ai.length); printf("ptr = %p\n", md.ai.ptr); md.ai[0] = 0; } void main() { meta!(__traits(getOverloads, S, "bar")[0]); meta!(S.bar); } Strangely dmd generates two functions and places two md objects in thread local storage (at least it reports do so). It seems that whatever __traits returns, is treated differently from S.bar. This leads to following problem. When above code is run, it outputs: length = 3 ptr = 0xc6c540 Segmentation fault So, thread local md object seems to be allocated, but array pointer is corrupted. If either of meta invocations is commented out, the code prints length = 3 ptr = 0x636298 So, pointer is valid. Ironically 0x636298 * 2 meta functions = 0xC6C530 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9442] typeid() doesn't work without `this.` for class fields
http://d.puremagic.com/issues/show_bug.cgi?id=9442 --- Comment #3 from github-bugzi...@puremagic.com 2013-02-04 00:36:40 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c589ba59462f1609da564723a90a72b920ab8483 fix Issue 9442 - typeid() doesn't work without `this.` for class fields https://github.com/D-Programming-Language/dmd/commit/aa51dadc917ccd844fb4f30a456b9fb40f316694 Merge pull request #1595 from 9rnsr/fix9442 Issue 9442 - typeid() doesn't work without `this.` for class fields -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---