[Issue 3180] Covariance of delegates/function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3180 yebblies changed: What|Removed |Added Keywords||patch Severity|normal |critical Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from yebblies 2011-09-06 02:02:19 PDT --- Part was fixed by https://github.com/D-Programming-Language/dmd/commit/dfb683f63ec89709b0bf2760ef3b2a249ce320eb Raising importance as while not a regression, this fixes one. (bug 6352) Pull for the remaining common type bugs: https://github.com/D-Programming-Language/dmd/pull/368 --- Comment #13 from yebblies 2011-09-06 02:03:45 PDT --- Part was fixed by https://github.com/D-Programming-Language/dmd/commit/dfb683f63ec89709b0bf2760ef3b2a249ce320eb Raising importance as while not a regression, this fixes one. (bug 6352) Pull for the remaining common type bugs: https://github.com/D-Programming-Language/dmd/pull/368 --- Comment #14 from Walter Bright 2011-09-16 23:28:48 PDT --- https://github.com/D-Programming-Language/dmd/commit/77bed134d06e6314c5b65465068f554b3f2c2e8d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6352] Regression(2.054) Implicit pure/nothrow/@safe messes up delegate arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6352 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright 2011-09-16 23:28:30 PDT --- https://github.com/D-Programming-Language/dmd/commit/77bed134d06e6314c5b65465068f554b3f2c2e8d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6674] Regression(2.055) mixin and __traits(allMembers) generates incorrect result
http://d.puremagic.com/issues/show_bug.cgi?id=6674 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2011-09-16 21:57:40 PDT --- https://github.com/D-Programming-Language/dmd/commit/aa02f484a6a697727706d7fb13764411322cf05d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6338] Immutability is lost for shared(immutable(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6338
Jerry Quinn changed:
What|Removed |Added
CC||jlqu...@optonline.net
--- Comment #2 from Jerry Quinn 2011-09-16 18:20:22 PDT
---
I think the collapsing might be required. I was going to report this
separately but it looks like a facet of your bug.
import std.stdio;
synchronized class foo {
File file;
this(string infile) {
file.open(infile);
}
}
~/dmd2/linux/bin64/dmd -c junk.d
junk.d(5): Error: function std.stdio.File.open (string name, in const(char[])
stdioOpenmode = "rb") is not callable using argument types (string) shared
/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/stdio.d(292): Error:
destructor std.stdio.File.~this () is not callable using argument types ()
The compiler (dmd 2.055) doesn't realize that shared(string) is equivalent to
string.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6683] Skipping declaration with goto resulted in nonsense
http://d.puremagic.com/issues/show_bug.cgi?id=6683 --- Comment #3 from Simen Kjaeraas 2011-09-16 17:47:46 PDT --- It's the latter. Not only do you run the risk of your variables being garbage, but your code might not compile on a future compiler. (not that this has ever *not* been a problem with D, mind) The compiler is free to issue an error or not, but the code is definitely wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6683] Skipping declaration with goto resulted in nonsense
http://d.puremagic.com/issues/show_bug.cgi?id=6683 --- Comment #2 from Adam D. Ruppe 2011-09-16 17:38:52 PDT --- Is that saying "bugs in the compiler don't override the spec" or "goto over initializations at your own risk"? If it's the latter, this isn't a bug at all. (I can see how the compiler throwing an error on this could get annoying, so I suppose it could go both ways.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6683] Skipping declaration with goto resulted in nonsense
http://d.puremagic.com/issues/show_bug.cgi?id=6683 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #1 from Simen Kjaeraas 2011-09-16 17:23:19 PDT --- The spec says "It is illegal for a GotoStatement to be used to skip initializations.". ( http://www.d-programming-language.org/statement.html#GotoStatement ) According to the glossary (http://www.d-programming-language.org/glossary.html), "A code construct is illegal if it does not conform to the D language specification. This may be true even if the compiler or runtime fails to detect the error." So the compiler is free to ignore illegal code. A future compiler, potentially not dmd, may indeed flag it as a compile-time error, so any behavior caused by illegal code should be regarded as unpredictable and unreliable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6683] New: Skipping declaration with goto resulted in nonsense
http://d.puremagic.com/issues/show_bug.cgi?id=6683
Summary: Skipping declaration with goto resulted in nonsense
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: destructiona...@gmail.com
--- Comment #0 from Adam D. Ruppe 2011-09-16
16:53:35 PDT ---
I'm in the middle of a project right now so will be brief and can add more
later.
Given code like such:
auto somethingResult = getSomething();
if(somethingResult.empty)
goto dont_have_something;
auto something = somethingResult.front;
dont_have_something:
if(something !is null) {
// potential problem here if the result was empty - "something" doesn't
refer to what I thought it would!
}
===
The goto over the variable declaration probably should have been a compile
error, I believe, from the spec. This was kinda a pain to find when it started
crashing since the variable actually referred to an entirely different object!
I'm using last month's dmd too, so possible it's already been fixed. I just
want to post something here before I forget about it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6682] Template function that has lazy parameter is not inferred as pure
http://d.puremagic.com/issues/show_bug.cgi?id=6682 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara 2011-09-16 15:58:11 PDT --- https://github.com/D-Programming-Language/dmd/pull/388 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6682] New: Template function that has lazy parameter does not inferred as pure
http://d.puremagic.com/issues/show_bug.cgi?id=6682
Summary: Template function that has lazy parameter does not
inferred as pure
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2011-09-16 14:17:37 PDT ---
By fixing bug 5750, the calcLazy should be inferred as pure, but it doesn't.
T calcLazy(T)(lazy T n)
{
return n;
}
int purefunc() pure
{
return calcLazy(1);
// test.d(8): Error: pure function 'purefunc' cannot call impure function
'calcLazy'
}
void main()
{
auto n = purefunc();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6275] Const values in tuples
http://d.puremagic.com/issues/show_bug.cgi?id=6275 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from bearophile_h...@eml.cc 2011-09-16 14:04:54 PDT --- Thank you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6275] Const values in tuples
http://d.puremagic.com/issues/show_bug.cgi?id=6275 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara 2011-09-16 13:19:06 PDT --- https://github.com/D-Programming-Language/phobos/pull/264 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4909] Two suggestions for std.algorithm.schwartzSort()
http://d.puremagic.com/issues/show_bug.cgi?id=4909 --- Comment #5 from bearophile_h...@eml.cc 2011-09-16 10:49:07 PDT --- (In reply to comment #4) > (That you unsubtly insert a typo, thus > underlining how you can't remember the right spelling?) I have not done that on purpose, I am sorry. But please trust me when I say I have problems with spelling that word :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6681] New: bogus duplicate union initialization or overlapping initialization errors
http://d.puremagic.com/issues/show_bug.cgi?id=6681
Summary: bogus duplicate union initialization or overlapping
initialization errors
Product: D
Version: D1 & D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: fa...@gmx.ch
--- Comment #0 from Fawzi Mohamed 2011-09-16 10:42:44 PDT ---
In D1 code like this
{{{
module t;
template MTuple( TList... )
{
alias TList MTuple;
}
struct V{
union {
double[2] cell;
version(v2) {} else {
MTuple!(double,double) tuple;
}
struct {
union { double x; double r; }
union { double y; double g; }
}
}
static const V zero={x:0, y:1};
}
V a=V.zero;
version(v2) {
struct Q {
union {
struct {
double x, y;
}
V xyzw;
}
const static Q id = { x: 0, y:1 };
}
Q b=Q.id;
}
}}}
fails with duplicate union initialization, which is incorrect.
This happens both with and without -version=v2 which shows that the error is
not just the tuple.
Closely related errors are present also in D2, even if one uses constructors:
{{{
module t;
template MTuple( TList... )
{
alias TList MTuple;
}
struct V{
this(double a,double b){
x=a;
y=b;
}
union {
double[2] cell;
version(v2) {} else {
MTuple!(double,double) tuple;
}
struct {
union { double x; double r; }
union { double y; double g; }
}
}
static immutable V zero=V(0,1);
}
V a=V.zero;
version(v2) {
struct Q {
union {
struct {
double x, y;
}
V xyzw;
}
immutable static Q id =Q(0,1);
}
Q b=Q.id;
}
}}}
similar errors seem to be very old:
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/6271.html
and there are related or very similar errors are already present in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=4241 which basically uses the
same code as me (omg derived vector structs), but just complains about line
number, seemingly accepting the error (which is bogus imho.
I have also tried to sprinkle around some =void but I just managed to end up
with "Error: no initializer for union".
http://d.puremagic.com/issues/show_bug.cgi?id=1432 (using initializers in the
union)
but this one at least with D1 is a regression from 1.067 at least
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4909] Two suggestions for std.algorithm.schwartzSort()
http://d.puremagic.com/issues/show_bug.cgi?id=4909 --- Comment #4 from Andrei Alexandrescu 2011-09-16 10:20:10 PDT --- (In reply to comment #3) > (In reply to comment #2) > > > Regarding naming, searching google etc. for schwartz sort yields relevant > > results whereas key sort does not. > > Schwartz sort is a common name and it's meaningful, but I am never able to > remember its correct spell. Being it a very common operation (I use it about > as > often as the normal sort), I think it's better to rename it with a name that's > simpler to remember (in spell) and maybe shorter too. Maybe Kagamin is not the > only person that agrees on this. If you are using schwartzSort heavily, it makes sense to define a local alias for it. At any rate, you may be overstating your case; if you use something as frequently as you claim, you _will_ know the spelling. > If you don't like keySort (I was just a quick idea), then we may search for > something else, that possibly uses only short and easy to spell English words. It's not about what I like or not. It's about doing sensible things. It doesn't seem sensible to simply decree that schwartzSort is inadequate to the extent it affects the productivity of people using it, and then solve the remaining problem of finding a different name for it. > Google is handy in many situations, but it's not the Alpha and Omega when you > have to give names to things. > > "Schwart sort" gives 9,500 hits. > "Decorate Sort Undecorate" gives 7,270 hits. What would be the argument here? (That you unsubtly insert a typo, thus underlining how you can't remember the right spelling?) > > Please refrain from suggesting name changes of public APIs unless they add > > significant value. > > Sorry, I'll keep suggesting what I think is better/right. You are of course welcome to do so, but I'm just suggesting to invest energy in things that may actually improve the state of affairs. You are suggesting a change of name from a name that is easily searchable and memorable to a name that you haven't even found yet but are sure is better. > Also, this enhancement request if from 2010-09, and I think I have said that > schwartzSort is a bad name from the beginning, from the first time I have seen > it. So it was not really a "name change". It's a name change now. The change didn't add value then, either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4909] Two suggestions for std.algorithm.schwartzSort()
http://d.puremagic.com/issues/show_bug.cgi?id=4909 --- Comment #3 from bearophile_h...@eml.cc 2011-09-16 09:58:00 PDT --- (In reply to comment #2) > Regarding naming, searching google etc. for schwartz sort yields relevant > results whereas key sort does not. Schwartz sort is a common name and it's meaningful, but I am never able to remember its correct spell. Being it a very common operation (I use it about as often as the normal sort), I think it's better to rename it with a name that's simpler to remember (in spell) and maybe shorter too. Maybe Kagamin is not the only person that agrees on this. If you don't like keySort (I was just a quick idea), then we may search for something else, that possibly uses only short and easy to spell English words. Google is handy in many situations, but it's not the Alpha and Omega when you have to give names to things. "Schwart sort" gives 9,500 hits. "Decorate Sort Undecorate" gives 7,270 hits. > Please refrain from suggesting name changes of public APIs unless they add > significant value. Sorry, I'll keep suggesting what I think is better/right. Also, this enhancement request if from 2010-09, and I think I have said that schwartzSort is a bad name from the beginning, from the first time I have seen it. So it was not really a "name change". It's a name change now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4909] Two suggestions for std.algorithm.schwartzSort()
http://d.puremagic.com/issues/show_bug.cgi?id=4909 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com --- Comment #2 from Andrei Alexandrescu 2011-09-16 09:07:36 PDT --- Omitting a string form for the transform is an oversight that should be fixed. Regarding naming, searching google etc. for schwartz sort yields relevant results whereas key sort does not. Please refrain from suggesting name changes of public APIs unless they add significant value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4961] ICE(interpret.c) Tuple in union as part of static struct member
http://d.puremagic.com/issues/show_bug.cgi?id=4961
Simen Kjaeraas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #2 from Simen Kjaeraas 2011-09-16 08:57:00
PDT ---
This example has been reduced to a limitation of CTFE. The original problem is
gone. The below code works as expected:
struct Fields4961 { int x; }
struct bar4961 {
union {
int[1] value;
Fields4961 fields;
}
this( int r ) {
fields.x = r;
}
}
static bar4961 b4961; // No longer initialized here. No CTFE problems.
static this( ) {
b4961 = bar4961( 0 );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4256] Inner template mathods can't access this pointer
http://d.puremagic.com/issues/show_bug.cgi?id=4256
Simen Kjaeraas changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Simen Kjaeraas 2011-09-16 08:48:05
PDT ---
This bug has grown worse. A lot worse. Good news: this now compiles:
struct foo {
int n;
void baz( ) {
void qux(T)() {
n = 3;
assert(n == 3); // Passes
}
qux!int();
}
}
void main( ) {
foo b;
assert(b.n == 0); // Passes
b.baz();
assert(b.n == 3); // Fails
}
As we can see, the change in n is not properly propagated. What's even worse,
is this:
struct foo {
int n;
void baz( ) {
void qux(T)(void* a) { // Added parameter
n = 3;
assert(n == 3); // Passes
assert(a == &this); // Added.
}
qux!int(&this);
}
}
void main( ) {
foo b;
assert(b.n == 0); // Passes
b.baz();
assert(b.n == 3); // No longer fails.
}
You can then remove the assert on line 7 (a == &this) to get the old behavior
back, the additional parameter changes nothing on its own.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1997] Better type inference for templated types
http://d.puremagic.com/issues/show_bug.cgi?id=1997
--- Comment #2 from Simen Kjaeraas 2011-09-16 08:17:12
PDT ---
It is worth noting here that the workaround is to use a free function:
struct Foo( T ) {
T data;
this( T value ) {
data = value;
}
}
Foo!T foo( T )( T value ) {
return Foo!T( value );
}
void main( ) {
foo( 4 );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4909] Two suggestions for std.algorithm.schwartzSort()
http://d.puremagic.com/issues/show_bug.cgi?id=4909 --- Comment #1 from bearophile_h...@eml.cc 2011-09-16 04:49:47 PDT --- See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=144557 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1824] Object not const correct
http://d.puremagic.com/issues/show_bug.cgi?id=1824 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #11 from Kenji Hara 2011-09-16 03:44:11 PDT --- I have posted patches. https://github.com/D-Programming-Language/dmd/pull/387 https://github.com/D-Programming-Language/druntime/pull/72 https://github.com/D-Programming-Language/phobos/pull/262 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3731] Can implicitly cast an immutable reference to a derived class
http://d.puremagic.com/issues/show_bug.cgi?id=3731 --- Comment #4 from Kenji Hara 2011-09-16 03:24:37 PDT --- I think issue 3731 is same as issue 5080, and the yebblies patch is a bit better than mine. See also Don and Steven's comments in 5080. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6296] ICE(glue.c): invalid template instantiated in is(typeof()).
http://d.puremagic.com/issues/show_bug.cgi?id=6296
--- Comment #18 from Don 2011-09-16 03:02:04 PDT ---
(In reply to comment #17)
> Still in dmd-1.x branch (tested after 23846ac and fe308a1).
> ---
> void f(A)(A) { }
> bool b = is(typeof( f(x) ));
> ---
Aargh, it was 6650 which was fixed, not this one!
I just copied the wrong bug number into the pull request (the commit itself
correctly names 6650).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
