[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 --- Comment #16 from Walter Bright --- (In reply to John Colvin from comment #14) > I'm marking this a regression as, whatever the reason, it worked with 2.065.0 > > Walter I've assigning you because it seems likely that > https://github.com/D-Programming-Language/dmd/commit/ > 6c2a2878200e0df1c73db976a747abf61b6a5e1a) and > (https://github.com/D-Programming-Language/druntime/commit/ > a405a02394e2c26c6a66c3fc5ef3777bb86cd973 caused it, but I'm not certain. That seems very unlikely, as those changes were dated June 2012, long before 2.065. --
[Issue 13152] Compiler high cpu usage and never ends
https://issues.dlang.org/show_bug.cgi?id=13152 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- I'm afraid you'll need to reduce the problem down a bit. --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #25 from Walter Bright --- Let's list a few objective facts: 1. The current situation (this bug report) occurs in the wild in real code in more than one project. Existing code is broken. 2. https://issues.dlang.org/show_bug.cgi?id=13148 has not been shown to occur anywhere in existing code, it is conjecture. A reason to write such code has not been demonstrated. 3. If there is a reason to write 13148 code, it can be fixed with the Unqual!ModuleInfo change. 4. In either solution, using ModuleInfo incorrectly will result in compiler errors, not silent corruption. Therefore it seems highly likely that there will be far more instances of requiring users to write immutable(ModuleInfo) than Unqual!ModuleInfo. Making ModuleInfo an immutable alias thus breaks far less existing code. (Inferring that an unadorned type name would necessarily be mutable comes as a surprise to me. This assumption is not stated anywhere in the documentation nor in common usage. A grep of phobos/std shows immutable aliases occurring. It's one of the things alias is for.) --
[Issue 8243] cannot initialize tuple with an element at module scope
https://issues.dlang.org/show_bug.cgi?id=8243
--- Comment #3 from timon.g...@gmx.ch ---
(In reply to hsteoh from comment #2)
> Why should this code be accepted? TypeTuple!(int,int) expects two
> initializers, but only one is specified.
The validity of this code should be consistent with the validity of the code
below:
alias Seq(T...)=T;
void main(){
Seq!(int,int) a=12;
}
We can also just disallow that code as well, those type tuple initializers
behave in a quite strange way anyway:
alias Seq(T...)=T
void main(){
int x=0;
Seq!(int,int) a=x++;
import std.stdio;
writeln(a); // "01"
}
--
[Issue 8243] cannot initialize tuple with an element at module scope
https://issues.dlang.org/show_bug.cgi?id=8243
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #4 from bearophile_h...@eml.cc ---
(In reply to timon.gehr from comment #3)
> alias Seq(T...)=T;
> void main(){
> Seq!(int,int) a=12;
> }
I suggest to disallow this.
--
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 --- Comment #17 from John Colvin --- (In reply to Walter Bright from comment #16) > That seems very unlikely, as those changes were dated June 2012, long before > 2.065. The issue existed before 2.065, but was somehow masked for a while. --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 --- Comment #18 from Walter Bright --- This is not a regression, it never worked. Nevertheless, I'm working on a fix. --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 --- Comment #19 from Walter Bright --- partial fix: https://github.com/D-Programming-Language/druntime/pull/901 --
[Issue 3396] Call of abstract method not detected by semantic check
https://issues.dlang.org/show_bug.cgi?id=3396 Denis Shelomovskij changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Hardware|x86 |All Resolution|--- |INVALID OS|Windows |All --- Comment #3 from Denis Shelomovskij --- This is a documented and intended behavior. According to [1]: > Functions declared as abstract can still have function bodies. This is so > that even though they must be overridden, they can still provide ‘base class > functionality.’ It also maches C++ behavior with respect to pure virtual functions. An enhancement request to change it may be opened but this bug is invalid. [1] http://dlang.org/attribute.html#abstract --
[Issue 13130] Syntax check fails when this is used as argument type
https://issues.dlang.org/show_bug.cgi?id=13130 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze --- I remember having seen this syntax before, but do you have a link to it being mentioned in the language spec? I have found postblit only, but that does not come with an identifier. I guess you are using DParser as the semantic engine (though probably the other engine doesn't accept it, too). --
[Issue 3206] Class used as its member function parameter's default value is considered implementating only lexically preceeding abstract functions
https://issues.dlang.org/show_bug.cgi?id=3206
Denis Shelomovskij changed:
What|Removed |Added
CC||verylonglogin@gmail.com
Summary|Cannot instantiate a class |Class used as its member
|implementing an abstract|function parameter's
|method |default value is considered
||implementating only
||lexically preceeding
||abstract functions
OS|Windows |All
--- Comment #1 from Denis Shelomovskij ---
---
class B { abstract void f(); }
class C: B
{
void g(C c = new C) { } // put after `f` to detrigger the issue
override void f() { }
}
---
Note `interface` implementations are not affected.
--
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #26 from Dicebot --- > In your code, you can have such aliases. But don't add such alias in standard > library code. It will introduce much limited situation than benefits. This is just your preference, there is nothing standard about it. Such solution is introduced exactly to impose limits and make using unqualified type harder. Forcing certain type to be always used as immutable is not unheard of which also means that you don't normally need const version of same type - because, well, it is always meant to be immutable. On actual topic: is there any reason why ModuleInfo itself needs to be immutable and marking all its data members is not enough? That should still make all the the options from PR #790 valid or am I missing something? --
[Issue 13155] New: Disallow final abstract classes
https://issues.dlang.org/show_bug.cgi?id=13155
Issue ID: 13155
Summary: Disallow final abstract classes
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code should NOT compile:
---
final abstract class C { }
---
Such classes are almost useless and generally indicate an error. Note unless
enhancement Issue 2946 is fixed the class may be derived as `abstract`:
---
final class C: B { }
---
`C` may or may no be `abstract` here depending on `B`. And one have to look
through every ancestor of `C` to determine whether it contains an unimplemented
`abstract` method.
--
[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract
https://issues.dlang.org/show_bug.cgi?id=2946
Denis Shelomovskij changed:
What|Removed |Added
CC||verylonglogin@gmail.com
--- Comment #13 from Denis Shelomovskij ---
1. Currently `abstract` in required if not all `interface` methods are
implemented or overridden with an `abstract` method:
---
interface I { void f(); }
abstract class CI1: I { } // `abstract` required
abstract class CI2: CI1 { } // `abstract` required too
class B { abstract void f(); }
class CB: B { } // derived as `abstract`
class CI3: I { abstract void f(); }
class CI4: CI3 { } // derived as `abstract` too
---
This difference looks inconsistent.
2. When one sees a class `C` and want to understand whether or not it is
abstract he has to look through every ancestor of `C` to determine whether it
contains an `abstract` method unimplemented further. And it's really hard. IMO
it would be much better if class declaration clearly shows whether it's
abstract or not.
3. Currently a compiler prints what methods are unimplemented if one tries to
create an abstract class instance so this isn't a critical issue, just a bad
looking thing in a language (IMHO).
--
[Issue 13156] New: `abstract` attribute should be disallowed in `interface`s
https://issues.dlang.org/show_bug.cgi?id=13156
Issue ID: 13156
Summary: `abstract` attribute should be disallowed in
`interface`s
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
`abstract` attribute should be disallowed in `interface`s in any way as it does
nothing except confuses people.
This code should NOT compile:
---
interface I
{
abstract void f(); // should be error
abstract { void g(); } // should be error
abstract: void h(); // should be error
}
---
--
[Issue 9978] Can override interface function
https://issues.dlang.org/show_bug.cgi?id=9978 Denis Shelomovskij changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Resolution|--- |INVALID --- Comment #3 from Denis Shelomovskij --- (In reply to Damian from comment #2) > [snip] > I'm not sure why both are allowed, even > though it does no harm to keep both, it seems one should be the right way > and the other a warning possibly? One can open an enhancement request for this, but this issue report is invalid. --
[Issue 2525] override of function from abstract base class's interface
https://issues.dlang.org/show_bug.cgi?id=2525 Denis Shelomovskij changed: What|Removed |Added CC||verylonglogin@gmail.com --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 Denis Shelomovskij changed: What|Removed |Added Summary|override of function from |Can't use `override` when |abstract base class's |implementing abstract base |interface |class's interface function OS|Linux |All --
[Issue 10699] override inconsistently allowed for abstract functions
https://issues.dlang.org/show_bug.cgi?id=10699 Denis Shelomovskij changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Denis Shelomovskij --- There is no `abstract` interface functions, see Issue 13156. *** This issue has been marked as a duplicate of issue 2525 *** --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 --- Comment #6 from Denis Shelomovskij --- *** Issue 10699 has been marked as a duplicate of this issue. *** --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 --- Comment #7 from Denis Shelomovskij --- *** Issue 12329 has been marked as a duplicate of this issue. *** --
[Issue 12329] override for implementing interface methods is not allowed in a subclass
https://issues.dlang.org/show_bug.cgi?id=12329 Denis Shelomovskij changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Denis Shelomovskij --- *** This issue has been marked as a duplicate of issue 2525 *** --
[Issue 13155] Disallow final abstract classes
https://issues.dlang.org/show_bug.cgi?id=13155 --- Comment #1 from Sobirari Muhomori --- In C# it's not an error, but a normal idiom when a class should not be inherited and instances should not be created. --
[Issue 13154] Incorrect init of static float array when sliced
https://issues.dlang.org/show_bug.cgi?id=13154 Kenji Hara changed: What|Removed |Added Keywords||pull, wrong-code Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/3783 --
[Issue 13155] Disallow final abstract classes
https://issues.dlang.org/show_bug.cgi?id=13155 --- Comment #2 from Denis Shelomovskij --- (In reply to Sobirari Muhomori from comment #1) > In C# it's not an error, but a normal idiom when a class should not be > inherited and instances should not be created. 1. In C# `class` can't be derived as `abstract`, it have to be explicitly marked so there is no `final class C` problem where reader may expect `C` to not be abstract. 2. In C# `class` can't be both `sealed` and `abstract` (error CS0418). Also there is `static` class syntax which ensures all class members are static and in D it's suggested to use modules with named imports for this purpose. Note: `static` classes are implemented as `abstract sealed` on IL level, but it's not visible for the user and is just a workaround for languages without support for static classes. --
[Issue 8243] cannot initialize tuple with an element at module scope
https://issues.dlang.org/show_bug.cgi?id=8243 --- Comment #5 from hst...@quickfur.ath.cx --- I think those look like bugs. While investigating a related issue recently, I noted that some parts of dmd don't appear to treat tuple types properly, so I wouldn't be surprised if things like what you posted are unintentional bugs. To me, it makes no sense to declare something with a tuple type of multiple items, yet the initializer receives only one argument. Even if this is intentionally allowed, I'd argue it's a misfeature because it makes it too easy for a typo to silently cause bugs. --
[Issue 12057] [ICE], backend/cg87.c 925
https://issues.dlang.org/show_bug.cgi?id=12057 --- Comment #3 from hst...@quickfur.ath.cx --- I take that back. This bug is still triggering when compiling with -O. I'm going to try to reduce it. --
[Issue 13149] released libphobos2.a is build with PIC code
https://issues.dlang.org/show_bug.cgi?id=13149 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13149] released libphobos2.a is build with PIC code
https://issues.dlang.org/show_bug.cgi?id=13149 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/88ab4d2227e05bb242bbe5c4cf1265e7254065ca fix Issue 13149 - released libphobos2.a is build with PIC code - Happens because the libphobos2.so was build with a recursive target and PIC=1. This PIC=1 enabled -fPIC for the recursive libdruntime.a build. - fixed by building $(LIBSO) non-recursively https://github.com/D-Programming-Language/phobos/commit/228aa04856364a2539c66c849d62852ec25b31c9 Merge pull request #2345 from MartinNowak/fix13149 fix Issue 13149 - released libphobos2.a is build with PIC code --
[Issue 3109] [meta] Template ordering
https://issues.dlang.org/show_bug.cgi?id=3109 Andrew Edwards changed: What|Removed |Added CC||edwards...@gmail.com --- Comment #1 from Andrew Edwards --- All bugs that this depends on were either closed or deemed invalid. Since it is only an aggregate of fixed bugs, I am marking it fixed. --
[Issue 3109] [meta] Template ordering
https://issues.dlang.org/show_bug.cgi?id=3109 Andrew Edwards changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 677] [Tracker] Get the documentation cleaned up for 1.0
https://issues.dlang.org/show_bug.cgi?id=677 Issue 677 depends on issue 3109, which changed state. Issue 3109 Summary: [meta] Template ordering https://issues.dlang.org/show_bug.cgi?id=3109 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13157] New: Enable unaliased construction and conversion for std.typecons.Unique
https://issues.dlang.org/show_bug.cgi?id=13157 Issue ID: 13157 Summary: Enable unaliased construction and conversion for std.typecons.Unique Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: ntrel-pub...@yahoo.co.uk Currently commented-out Unique code should be updated and tested to: 1. Enable unaliased construction of the unique resource by wrapping resource constructor. 2. Enable transferring Unique!Derived rvalue to Unique!Base. --
[Issue 13157] Enable unaliased construction and conversion for std.typecons.Unique
https://issues.dlang.org/show_bug.cgi?id=13157 Nick Treleaven changed: What|Removed |Added Keywords||pull --- Comment #1 from Nick Treleaven --- https://github.com/D-Programming-Language/phobos/pull/2346 --
[Issue 12057] [ICE], backend/cg87.c 925
https://issues.dlang.org/show_bug.cgi?id=12057
--- Comment #4 from hst...@quickfur.ath.cx ---
Minimal failing test case:
-
// Compile with: dmd -O
bool prop(real x) { return false; }
double f(real) { return double.init; }
void main()
{
real fc = f(real.init);
if (fc == 0 || fc.prop) {}
}
-
The ICE goes away if compiling without -O. Looks like an optimizer bug.
--
[Issue 12057] [ICE], backend/cg87.c 925
https://issues.dlang.org/show_bug.cgi?id=12057 hst...@quickfur.ath.cx changed: What|Removed |Added Severity|major |critical --
[Issue 8243] cannot initialize tuple with an element at module scope but this is allowed in function-local scopes
https://issues.dlang.org/show_bug.cgi?id=8243
timon.g...@gmx.ch changed:
What|Removed |Added
Summary|cannot initialize tuple |cannot initialize tuple
|with an element at module |with an element at module
|scope |scope but this is allowed
||in function-local scopes
--- Comment #6 from timon.g...@gmx.ch ---
(In reply to hsteoh from comment #5)
> I think those look like bugs. While investigating a related issue recently,
> I noted that some parts of dmd don't appear to treat tuple types properly,
> so I wouldn't be surprised if things like what you posted are unintentional
> bugs. To me, it makes no sense to declare something with a tuple type of
> multiple items, yet the initializer receives only one argument.
This is allowed too:
void main(){ int[2] x=2; }
> Even if this is intentionally allowed,
I'd assume so, though /maybe/ the duplication of side-effects is unintentional.
> I'd argue it's a misfeature because it makes it
> too easy for a typo to silently cause bugs.
I don't disagree at all, but the behaviour should in any case be consistent.
--
[Issue 3396] Call of abstract method not detected by semantic check
https://issues.dlang.org/show_bug.cgi?id=3396 Stewart Gordon changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #4 from Stewart Gordon --- (In reply to Denis Shelomovskij from comment #3) > This is a documented and intended behavior. According to [1]: >> Functions declared as abstract can still have function bodies. But A.M has no function body. So what's the relevance? >> This is so that even though they must be overridden, they can >> still provide ‘base class functionality.’ But no base class functionality has been provided. As such, the compiler cannot resolve the call to super.M and therefore should error. > It also maches C++ behavior with respect to pure virtual functions. What exactly does the C++ standard say about this? That said, is C++ behaviour relevant? D is not C++. --
[Issue 12754] MAC link error for template to static value
https://issues.dlang.org/show_bug.cgi?id=12754 --- Comment #2 from monarchdo...@gmail.com --- Has anybody from the DMD team seen this report? I don't need a fix asap or anything, but just confirmation that someone knows about it would be nice. --
[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
https://issues.dlang.org/show_bug.cgi?id=2834 --- Comment #22 from Orvid King --- Ok, so, to give an update on this issue, I've now implemented the invoking of destructors on heap allocated structs, as well as arrays of structs. It required a fix to a bug in DMD with the delete operator, as well as a change (which I still need to make), to the test suite so that it doesn't allocate in a destructor. The DMD PR is here: https://github.com/D-Programming-Language/dmd/pull/3727 And the druntime PR, as mentioned farther up, is here: https://github.com/D-Programming-Language/druntime/pull/864 --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #27 from Jacob Carlborg --- (In reply to Dicebot from comment #26) > On actual topic: is there any reason why ModuleInfo itself needs to be > immutable and marking all its data members is not enough? That should still > make all the the options from PR #790 valid or am I missing something? Exactly, I've already asked that but didn't get a reply on that question. Is it possible to write to the pointer that will cause problems? --
[Issue 12754] MAC link error for template to static value
https://issues.dlang.org/show_bug.cgi?id=12754 --- Comment #3 from hst...@quickfur.ath.cx --- You might want to post this on the newsgroup/forum. I appear to be the only other user on the Cc list for this bug. :-P --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 --- Comment #20 from Walter Bright --- Rest of the fix: https://github.com/D-Programming-Language/dmd/pull/3784 --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --
[Issue 13158] New: D:YAML broken by 2.066
https://issues.dlang.org/show_bug.cgi?id=13158
Issue ID: 13158
Summary: D:YAML broken by 2.066
Product: D
Version: unspecified
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: kiithsa...@gmail.com
I started testing 2.066b4 and noticed that my library D:YAML is broken.
I minimized the cause of the bug to the following:
==
import std.variant;
struct Node
{
struct Pair
{
Node value;
}
alias Algebraic!(Node[], int) Value;
}
void main(string[] args)
{
}
==
This compiles with DMD 2.065 and doesn't compile with 2.066b4.
It seems to break at std.variant.maxSize.
Build log:
==
/home/kiith-sa/Programming/D/Compilers/dmd2066-beta/linux/bin64/../../src/phobos/std/variant.d(84):
Error: void has no value
/home/kiith-sa/Programming/D/Compilers/dmd2066-beta/linux/bin64/../../src/phobos/std/variant.d(84):
Error: incompatible types for ((16LU) >= (maxSize!int)): 'ulong' and 'void'
/home/kiith-sa/Programming/D/Compilers/dmd2066-beta/linux/bin64/../../src/phobos/std/variant.d(1245):
Error: template instance std.variant.maxSize!(Node[], int) error instantiating
bug.d(10):instantiated from here: Algebraic!(Node[], int)
/home/kiith-sa/Programming/D/Compilers/dmd2066-beta/linux/bin64/../../src/phobos/std/variant.d(1245):
Error: template instance VariantN!(maxSize!(Node[], int), Node[], int) does not
match template declaration VariantN(ulong maxDataSize, AllowedTypesX...)
==
This compiles without an error with 2.066b4 (as well as 2.065):
==
import std.variant;
struct Pair
{
Node value;
}
struct Node
{
alias Pair = .Pair;
alias Algebraic!(Node[], int) Value;
}
void main(string[] args)
{
}
==
--
[Issue 13156] `abstract` attribute should be disallowed in `interface`s
https://issues.dlang.org/show_bug.cgi?id=13156 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 13130] Syntax check fails when this is used as argument type
https://issues.dlang.org/show_bug.cgi?id=13130
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #2 from hst...@quickfur.ath.cx ---
Shouldn't that be:
this(typeof(this) other) { ... }
? Is this a case of accepts-invalid?
--
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from hst...@quickfur.ath.cx --- Fixed in git HEAD (as currently shown on dlang.org under the Phobos prerelease section). --
[Issue 1161] [module] Access to private static members is allowed from other module.
https://issues.dlang.org/show_bug.cgi?id=1161 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx Version|D1 & D2 |D1 --- Comment #9 from hst...@quickfur.ath.cx --- Seems to have been fixed in git HEAD (D2): the compiler now says, for the original test case: static_a.d(4): Error: class static_b.Test member counter is not accessible Removing D2 tag. --
[Issue 2195] Variable shadowing in foreach is not detected and reported
https://issues.dlang.org/show_bug.cgi?id=2195 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #9 from hst...@quickfur.ath.cx --- Still present in git HEAD, compiler accepts the code without error. --
[Issue 13155] Disallow final abstract classes
https://issues.dlang.org/show_bug.cgi?id=13155 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis --- I very much doubt that this will ever happen. It's used at least one place in Phobos (std.process.environment). Basically, it allows you to create a namespace within a module or to have a global singleton of sorts. You can do something similar by declaring a class whose default constructor is disabled, but regardless, some people are definitely using final abstract (or abstract final) on purpose, so I don't expect that it will ever become illegal. --
[Issue 4903] opopAssignRight is needed for operator overloading
https://issues.dlang.org/show_bug.cgi?id=4903 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11734] undefined behavior with dirEntries
https://issues.dlang.org/show_bug.cgi?id=11734
Andrew Edwards changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||edwards...@gmail.com
Resolution|--- |WORKSFORME
--- Comment #1 from Andrew Edwards ---
This problem does not exist in v2.066.0-b4. I've verified on OSX 10.9, Debian
7.4, and Ubuntu 12.04 LTS with nb_dirs set to 50, 500, 5000, and 5.
Additional testing conducted on Ubuntu using the following script:
#!/bin/bash
for i in {5..100..5}
do
rm -rf /tmp/some_temp_dir/ && dmd -run bug /tmp/some_temp_dir/ $i
done
No issues encountered.
--
[Issue 6936] type combination is not commutative
https://issues.dlang.org/show_bug.cgi?id=6936 --- Comment #1 from hst...@quickfur.ath.cx --- Isn't this more a problem with type inference in the ternary '?' operator? --
[Issue 6936] type combination is not commutative
https://issues.dlang.org/show_bug.cgi?id=6936 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis --- (In reply to hsteoh from comment #1) > Isn't this more a problem with type inference in the ternary '?' operator? Yes. The ternary operator currently, incorrectly uses the type of its last argument rather than the common type of the second and third arguments. It's essentially the same bug as issue# 3543, but this is with arrays, whereas 3543 specifically talks about classes and interfaces, so I'm not sure if it's actually a duplicate. --
[Issue 13158] D:YAML broken by 2.066
https://issues.dlang.org/show_bug.cgi?id=13158 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Version|unspecified |D2 --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #28 from Walter Bright --- (In reply to Jacob Carlborg from comment #27) > (In reply to Dicebot from comment #26) > > > On actual topic: is there any reason why ModuleInfo itself needs to be > > immutable and marking all its data members is not enough? That should still > > make all the the options from PR #790 valid or am I missing something? > > Exactly, I've already asked that but didn't get a reply on that question. Is > it possible to write to the pointer that will cause problems? ModuleInfo is a variable sized struct that is decoded at runtime. The two explicit fields are only the start of it. Making the whole thing immutable makes the intent clear. --
[Issue 13154] Incorrect init of static float array when sliced
https://issues.dlang.org/show_bug.cgi?id=13154 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/41c9adce2818e469c32af2c7cfba61f906c4623a fix Issue 13154 - Incorrect init of static float array when sliced https://github.com/D-Programming-Language/dmd/commit/39f6d3b508cf26fdc43d9b226c1704f05ffd5061 Merge pull request #3783 from 9rnsr/fix13154 [REG2.066a] Issue 13154 - Incorrect init of static float array when sliced --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 --- Comment #21 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/4a8ca65688d2f5be290087c4b1f078c508fc7272 parial Issue 9449 - Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii https://github.com/D-Programming-Language/druntime/commit/3626a88e1dee58a88969f6bbfc5a1b1c74d0dee5 Merge pull request #901 from WalterBright/fix9449 [critical] partial Issue 9449 - Static arrays of 128bit types segfault on initializa... --
