[Issue 7398] New: spell checker should suppress error messages
http://d.puremagic.com/issues/show_bug.cgi?id=7398
Summary: spell checker should suppress error messages
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2012-01-30 00:02:25 PST ---
class T2
{
alias Foo.value value;
static struct Foo
{
private static int value;
}
}
void foo()
{
auto val = T2.value;
}
b.d(5): Error: struct b.T2.Foo is forward referenced when looking for 'value'
... ~80.000 more error messages
b.d(5): Error: struct b.T2.Foo is forward referenced when looking for 'value__'
b.d(3): Error: no property 'value' for type 'Foo'
b.d(3): Error: alias b.T2.value cannot alias an expression __error
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-01-30 01:20:02 PST --- The failure definitely happened between 2.056 and 2.057. Anyone care to run the git binary diff thing? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-01-30 02:02:19 PST --- Auch, I found it. In druntime/src/rt/cast_.d, the addition of a name compare saying the classes are the same in _d_isbaseof and _d_isbaseof2. Not sure what the right fix is. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2012-01-30 02:04:29 PST --- The culprit: https://github.com/D-Programming-Language/druntime/commit/5d21d47b5adda97759d15ec0139c0d5fac646971 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #8 from Iain Buclaw ibuc...@ubuntu.com 2012-01-30 03:09:44 PST ---
(In reply to comment #6)
I would suggest the problem is with the way gdc is doing alignment.
align:
means the default alignment that matches the C compiler. dmd and gdc need to
do
whatever it takes to make that happen. Adding another align directive just
confuses things.
From the spec:
---
Align Attribute specifies the alignment of struct members. align by itself sets
it to the default, which matches the default member alignment of the companion
C compiler.
---
GDC matches the companion GCC compiler, in that we have a callback to get the
field alignment for the type, which may not necessarily the same as the type
alignment, as some architectures (i.e. i386) limit struct field alignment to a
lower boundary than alignment of some types of variables.
From the spec:
---
Integer specifies the alignment which matches the behavior of the companion C
compiler when non-default alignments are used.
---
GDC matches the companion GCC compiler here as well, in that:
struct S {
align(4) byte a; // placed at offset 0
align(4) byte b; // placed at offset 4
}
This is achieved by adding a declalign field in VarDeclaration that takes
precedence over the type align.
This I think is different from how DMC++ treats the align attribute, which is
where the conflict of interest arises.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7373] (Regression git) Renamed imports conflict with other implicitly imported symbols
http://d.puremagic.com/issues/show_bug.cgi?id=7373 --- Comment #3 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-01-30 03:11:07 PST --- Thanks for the fix. Maybe it would be a good idea to add the test case to the test suite to make sure this will never break again. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2012-01-30 03:19:50 PST --- This I think is different from how DMC++ treats the align attribute, which is where the conflict of interest arises. Which means that dmd should change to match gcc for gcc platforms. The addition of an align(0) is not the right solution. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #10 from Iain Buclaw ibuc...@ubuntu.com 2012-01-30 03:55:12 PST --- (In reply to comment #9) This I think is different from how DMC++ treats the align attribute, which is where the conflict of interest arises. Which means that dmd should change to match gcc for gcc platforms. The addition of an align(0) is not the right solution. It's not an addition of align(0) - although currently I think the parser will accept any non-negative integer, which needs to be addressed. The point Daniel raised in question is that it would be helpful if there was information available so we could tell the difference between whether the user specified align: or align(n), so we can do the right thing accordingly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2172] statically disallow bool + bool
http://d.puremagic.com/issues/show_bug.cgi?id=2172 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2012-01-30 04:28:27 PST --- The error message looks clear. And and this point I don't think D boolean semantics will change. So I think this bug report needs to be closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2563] Derived class is implicitly castable to Base class when inherited privately
http://d.puremagic.com/issues/show_bug.cgi?id=2563 --- Comment #7 from Stewart Gordon s...@iname.com 2012-01-30 04:33:58 PST --- (In reply to comment #6) D1 only now, as of issue 5299 private inheritance is deprecated in D2. But it hasn't actually _worked_ in D1 for some time, and the spec has never actually given its meaning. As such, it would be to the point to just remove it from the grammar or at least issue a warning when one tries to use it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2172] statically disallow bool + bool
http://d.puremagic.com/issues/show_bug.cgi?id=2172 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from yebblies yebbl...@gmail.com 2012-01-31 02:17:02 EST --- I tend to agree. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2563] Derived class is implicitly castable to Base class when inherited privately
http://d.puremagic.com/issues/show_bug.cgi?id=2563 --- Comment #8 from yebblies yebbl...@gmail.com 2012-01-31 02:29:01 EST --- (In reply to comment #7) But it hasn't actually _worked_ in D1 for some time, and the spec has never actually given its meaning. As such, it would be to the point to just remove it from the grammar or at least issue a warning when one tries to use it. Yes... I don't recall stating anything to the contrary. If you thing the same fix (or a different fix) should be applied to D1 please reopen the closed issue (or a new issue) with that information. This bug is about the protection issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #11 from Daniel Green ven...@gmail.com 2012-01-30 08:06:37 PST --- (In reply to comment #9) The addition of an align(0) is not the right solution. Currently, `align:` becomes`align(8)`. Ambiguous. default alignment or 8 byte? Using 0, `align:` becomes `align(0)`. Now if 0, default alignment is requested. I'm not suggesting adding align(0). I'm suggesting setting the internal variable to 0 when default alignment is wanted. The reason for this is the knowledge that default alignment is required is only available to the parser and not saved. The biggest issue with this method is that if new code is added which uses the structalign field of a scope block. It must also check for 0. This could be alleviated by removing direct access to structalign and adding 2 member functions. Scope::alignsize() - return (structalign ? structalign : global.structalign); Scope::isDefaultAlignment() - return !structalign --- The original patch is designed to allow GDC to do what it's been doing without breaking DMD or diverging the source more than necessary. Since you have suggested DMD should change to match gcc on gcc platforms. It should be considered invalid as any solution for DMD will solve the problem for GDC as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #6 from yebblies yebbl...@gmail.com 2012-01-31 03:14:09 EST --- I suspected is was that commit. (I remember seeing it when it was committed) Sorry I didn't get around to looking into it earlier. I think the solution is to do a compare on the full mangled name of the class, but I can't see anywhere it's exposed in the classinfo so it would need to be added. This should probably be delayed until after the release and the commit reverted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7399] New: Broken import statement in trySemantic() causes silent compiler error
http://d.puremagic.com/issues/show_bug.cgi?id=7399
Summary: Broken import statement in trySemantic() causes silent
compiler error
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 klickverbot c...@klickverbot.at 2012-01-30 08:40:40 PST
---
Consider:
---
pragma(msg, __traits(compiles, { import non.existent.file; }));
---
Errors are gagged during sema of the import statement, but Module::read calls
fatal(), causing DMD to exit without any error message being printed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7400] New: failing local imports not fully gagged in is expression
http://d.puremagic.com/issues/show_bug.cgi?id=7400
Summary: failing local imports not fully gagged in is
expression
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-01-30 08:46:30 PST ---
DMD 2.057
// module asdf does not exist
static if(is(typeof({import asdf;}))){}
The compilation fails with no error messages and exit code 1.
The code should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7399] Broken import statement in trySemantic() causes silent compiler error
http://d.puremagic.com/issues/show_bug.cgi?id=7399 klickverbot c...@klickverbot.at changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1 from klickverbot c...@klickverbot.at 2012-01-30 08:47:44 PST --- *** Issue 7400 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 7400] failing local imports not fully gagged in is expression
http://d.puremagic.com/issues/show_bug.cgi?id=7400 klickverbot c...@klickverbot.at changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@klickverbot.at Resolution||DUPLICATE --- Comment #1 from klickverbot c...@klickverbot.at 2012-01-30 08:47:44 PST --- *** This issue has been marked as a duplicate of issue 7399 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 926] Revival of implicit conversion from Derived[] to Base[] not noted in changelog
http://d.puremagic.com/issues/show_bug.cgi?id=926 Stewart Gordon s...@iname.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | AssignedTo|bugzi...@digitalmars.com|s...@iname.com --- Comment #7 from Stewart Gordon s...@iname.com 2012-01-30 08:55:26 PST --- (In reply to comment #6) What matters is what the spec says and what the compiler does now. If someone wants to go through the compiler/spec diffs from years ago to see when things changed, that's fine and I'll fold in changelog changes if they present them, The standard meaning of WONTFIX is this issue is to stay as it is not I personally can't be bothered/don't have time to deal with it. The way to indicate the latter is to leave it open and reassign it to nobody - this shows that it's free for anybody to take the issue and work on it. Here's an idea: I'll have a look at it myself over the next few days. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #7 from d...@dawgfoto.de 2012-01-30 09:39:05 PST --- This was introduced by pull #92 https://github.com/D-Programming-Language/druntime/commits/29f33bfdc0d36484e77ae8f369656720319f22e3. This added classinfo.name comparison while searching base classes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #8 from d...@dawgfoto.de 2012-01-30 10:01:25 PST --- https://github.com/D-Programming-Language/druntime/pull/142 -- 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 Don clugd...@yahoo.com.au changed: What|Removed |Added AssignedTo|nob...@puremagic.com|clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2012-01-30 10:54:29 PST --- I've made a fix for this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #9 from github-bugzi...@puremagic.com 2012-01-30 11:12:29 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3a6c3629f3185c2d65354d1f04c500eb737d49d9 fix Issue 7375 - Regression(2.057): Invalid downcast permitted with derived/aliased template classes https://github.com/D-Programming-Language/dmd/commit/667ff95c935bc1cf743517b69d2dc421e43f9a51 fix Issue 7375 - Regression(2.057): Invalid downcast permitted with derived/aliased template classes -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #10 from github-bugzi...@puremagic.com 2012-01-30 11:12:36 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/06a33d14f9ad137d86309d40180ca0e60f4edb74 fix Issue 7375 - Regression(2.057): Invalid downcast permitted with derived/aliased template classes -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 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 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2012-01-30 11:17:53 PST --- I fixed this in the compiler, not the runtime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #12 from Walter Bright bugzi...@digitalmars.com 2012-01-30 11:21:01 PST --- (In reply to comment #11) Currently, `align:` becomes`align(8)`. Ambiguous. default alignment or 8 byte? This is the misunderstanding. align: means align to the C compiler default. IT DOES NOT MEAN align(8). How it is implemented under the hood is IRRELEVANT. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 926] Revival of implicit conversion from Derived[] to Base[] not noted in changelog
http://d.puremagic.com/issues/show_bug.cgi?id=926 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2012-01-30 11:27:08 PST --- (In reply to comment #7) Here's an idea: I'll have a look at it myself over the next few days. I'll be happy to merge in any changes you suggest. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #13 from Daniel Green ven...@gmail.com 2012-01-30 11:40:30 PST --- (In reply to comment #12) (In reply to comment #11) Currently, `align:` becomes`align(8)`. Ambiguous. default alignment or 8 byte? This is the misunderstanding. align: means align to the C compiler default. IT DOES NOT MEAN align(8). How it is implemented under the hood is IRRELEVANT. It is RELEVANT because that information is THROWN AWAY during parsing. ONLY the PARSER knows that C compiler default alignment is required and DOES NOT convey that information in any form. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #14 from Daniel Green ven...@gmail.com 2012-01-30 12:01:15 PST ---
The statement:
`align:` becomes `align(8)`
in based entirely on how the parser handles the align attribute.
// excerpt from parse.c line 503.
case TOKalign:
{ unsigned n;
s = NULL;
nextToken();
if (token.value == TOKlparen)
{
nextToken();
if (token.value == TOKint32v token.uns64value 0)
n = (unsigned)token.uns64value;
else
{ error(positive integer expected, not %s, token.toChars());
n = 1;
}
nextToken();
check(TOKrparen);
}
else
n = global.structalign; // default
a = parseBlock();
s = new AlignDeclaration(n, a);
break;
}
When `align:` is encountered n is set to global.structalign. This makes the
statement equal to `align(8)`.
It's not that I don't understand that `align:` means default alignment and
should be treated differently than `align(8)`. It's that only the parser knows
that and currently doesn't convey that information.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #15 from Walter Bright bugzi...@digitalmars.com 2012-01-30 12:20:04 PST --- Right, it's a compiler issue. Not a language issue, and no new language features or syntax are required. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #16 from Daniel Green ven...@gmail.com 2012-01-30 12:23:45 PST ---
(In reply to comment #15)
Right, it's a compiler issue. Not a language issue, and no new language
features or syntax are required.
Yes, I agree. My proposal was the following.
// excerpt from parse.c line 503.
case TOKalign:
{ unsigned n;
s = NULL;
nextToken();
if (token.value == TOKlparen)
{
nextToken();
if (token.value == TOKint32v token.uns64value 0)
n = (unsigned)token.uns64value;
else
{ error(positive integer expected, not %s, token.toChars());
n = 1;
}
nextToken();
check(TOKrparen);
}
else
-n = global.structalign; // default
+n = 0; // default
a = parseBlock();
s = new AlignDeclaration(n, a);
break;
}
Now the compiler can test for 0 and know that default alignment is required.
This removes the ambiguity with the current implementation.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2483] DMD allows assignment to a scope variable
http://d.puremagic.com/issues/show_bug.cgi?id=2483 --- Comment #5 from github-bugzi...@puremagic.com 2012-01-30 12:24:53 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b0f5018d1c28cf1129c5eeb111262dbcf4a13d02 fix Issue 2483 - DMD allows assignment to a scope variable -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2483] DMD allows assignment to a scope variable
http://d.puremagic.com/issues/show_bug.cgi?id=2483 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 7365] [Regression after 2.057] AAs broken for Object keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7365 --- Comment #2 from github-bugzi...@puremagic.com 2012-01-30 12:35:44 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ba943d54d4f97ec98261d5d00631aecbea7cdbea add test case for issue 7365 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7365] [Regression after 2.057] AAs broken for Object keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7365 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WORKSFORME --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-01-30 12:36:36 PST --- It works for me, but I added a test case for it anyway to the test suite. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7365] [Regression after 2.057] AAs broken for Object keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7365 --- Comment #4 from klickverbot c...@klickverbot.at 2012-01-30 12:48:27 PST --- Seems to WORKSFORME now as well, not sure when it was fixed or what the problem was before… -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7365] [Regression after 2.057] AAs broken for Object keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7365 klickverbot c...@klickverbot.at changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #5 from klickverbot c...@klickverbot.at 2012-01-30 12:51:10 PST --- Ah, screw it, now the auto-tester fails because of it as well: http://d.puremagic.com/test-results/test_data.ghtml?dataid=146136. Must have inadvertently introduced a workaround in my original client code, sorry for the noise. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7401] New: Pure contracts Unnecessarily strict
http://d.puremagic.com/issues/show_bug.cgi?id=7401
Summary: Pure contracts Unnecessarily strict
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rtcv...@yahoo.com
--- Comment #0 from Era Scarecrow rtcv...@yahoo.com 2012-01-30 14:23:53 PST
---
The compiler complaining to me that my function isn't 'pure' by calling a
non-pure function, specifically to!string().
However the unpure functions used are only accessed in the contracts (and only
if it failed). The contracts shouldn't be considered as part of the pure
contract. This is because they are totally excluded during the release builds
(and shouldn't have any side effects anyways).
Error: pure function 'offset' cannot call impure function 'to'
struct X
{
int size;
...
const pure int offset(int field)
out(o)
{
assert(o = 0, Negative value! Check structure: ~ to!string(size) ~
\n);
}
body { ... }
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7401] Pure contracts Unnecessarily strict
http://d.puremagic.com/issues/show_bug.cgi?id=7401 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2012-01-30 14:43:21 PST --- See also issue 7224 (that asks kind of the opposite) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7401] Pure contracts Unnecessarily strict
http://d.puremagic.com/issues/show_bug.cgi?id=7401
--- Comment #2 from Era Scarecrow rtcv...@yahoo.com 2012-01-30 14:55:06 PST
---
(In reply to comment #1)
See also issue 7224 (that asks kind of the opposite)
In his remark, it seems rather silly. Of course it won't raise an exception
when it's in release mode, the in contract won't even be present.
However with the pure contract, I don't want to have to encompass a debug{}
block to show my assert details. Then I need the -debug flag on as well
otherwise it won't be checked, unless you go around it...
in {
string message = use -debug or pure gets in the way;
debug {
message = to!string();
}
assert(something, x);
}
or
in {
debug {
assert(something, with message);
}
assert(something); //same assert as above but doesn't give a useful message.
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7401] Pure contracts Unnecessarily strict
http://d.puremagic.com/issues/show_bug.cgi?id=7401 --- Comment #3 from bearophile_h...@eml.cc 2012-01-30 15:07:54 PST --- I think the right solution for this problem is to wait for to!string(int) to become pure. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7402] New: Appending enum string causes type change?
http://d.puremagic.com/issues/show_bug.cgi?id=7402
Summary: Appending enum string causes type change?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jus...@economicmodeling.com
--- Comment #0 from Justin Whear jus...@economicmodeling.com 2012-01-30
15:17:00 PST ---
This program:
enum TEST = test;
string valid = this is a ~ TEST;
char[] sabotage = cast( char[] )this is a ~ TEST;
string no_longer_valid = this is a ~ TEST;
void main() {}
Fails to compile with this error:
Error: cannot implicitly convert expression (this is a test) of type char[]
to string
Commenting out the char[] sabotage... allows the program to compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7397] [Regression] std.path.buildPath can't be used with string[]
http://d.puremagic.com/issues/show_bug.cgi?id=7397 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-01-30 15:18:14 PST --- https://github.com/D-Programming-Language/phobos/pull/412 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7365] [Regression after 2.057] AAs broken for Object keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7365 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7365] [Regression after 2.057] AAs broken for Object keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7365 --- Comment #6 from github-bugzi...@puremagic.com 2012-01-30 16:31:00 PST --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/048caceac7c678b16ccd0f602a6a622a5ba3 fix Issue 7365 - [Regression after 2.057] AAs broken for Object keys and values with opEquals -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7404] New: std.range.SortedRange.release() property
http://d.puremagic.com/issues/show_bug.cgi?id=7404
Summary: std.range.SortedRange.release() property
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-01-30 17:35:57 PST ---
Is std.range.SortedRange.release() better as a (pure nothrow) @property?
Its current (2.058head) implementation:
/**
Releases the controlled range and returns it.
*/
auto release()
{
return move(_input);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7405] New: std.algorithm.schwartzSort.release
http://d.puremagic.com/issues/show_bug.cgi?id=7405 Summary: std.algorithm.schwartzSort.release Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2012-01-30 17:39:39 PST --- I think std.algorithm.schwartzSort should have an usage more uniform with std.algorithm.sort(), and I think release is handy to write expressions, so I suggest to add a release to std.algorithm.schwartzSort too. See also bug 7404 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7404] std.range.SortedRange.release() property
http://d.puremagic.com/issues/show_bug.cgi?id=7404 --- Comment #1 from bearophile_h...@eml.cc 2012-01-30 17:40:04 PST --- See also issue 7405 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7258] std.array.array of const items
http://d.puremagic.com/issues/show_bug.cgi?id=7258 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86 |All OS/Version|Windows |All Severity|enhancement |normal -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #17 from d...@dawgfoto.de 2012-01-30 17:58:26 PST --- https://github.com/D-Programming-Language/dmd/pull/657 The pull request additionally solves the broken header generation for default align. Also note that adding this won't change the meaning of align(0), as 0 is already an error. PS: We should definitely check at some point that alignment is a power of two. There is already code relying on this (AggregateDeclaration::alignmember). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7402] Appending enum string causes type change?
http://d.puremagic.com/issues/show_bug.cgi?id=7402 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||rejects-valid, wrong-code CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 13:07:31 EST --- Probably related to issue 6504. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5080] breaking const-correctness with class/interface
http://d.puremagic.com/issues/show_bug.cgi?id=5080 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #10 from yebblies yebbl...@gmail.com 2012-01-31 13:13:15 EST --- *** This issue has been marked as a duplicate of issue 3731 *** -- 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 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #7 from yebblies yebbl...@gmail.com 2012-01-31 13:13:15 EST --- *** Issue 5080 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 3759] Implementing two interfaces with same final function is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=3759 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Platform|x86 |All Version|2.040 |D2 Resolution||DUPLICATE OS/Version|Windows |All --- Comment #3 from yebblies yebbl...@gmail.com 2012-01-31 13:34:12 EST --- *** This issue has been marked as a duplicate of issue 4647 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4647] [tdpl] Cannot explicitly call final interface method, ambiguous calls allowed
http://d.puremagic.com/issues/show_bug.cgi?id=4647 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||a...@esperanto.org.ar --- Comment #6 from yebblies yebbl...@gmail.com 2012-01-31 13:34:12 EST --- *** Issue 3759 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 1973] static on interfaces should be an error
http://d.puremagic.com/issues/show_bug.cgi?id=1973 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Version|1.028 |D1 D2 Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 13:41:52 EST --- Static no longer propagates to the interface members. Asking for an error on this is a dup of issue 3934. *** This issue has been marked as a duplicate of issue 2553 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2553] Excess attribute propagation for interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=2553 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||ben...@tionex.de --- Comment #3 from yebblies yebbl...@gmail.com 2012-01-31 13:41:52 EST --- *** Issue 1973 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 3969] Built-in compile time errors against usage of wrong operator strings
http://d.puremagic.com/issues/show_bug.cgi?id=3969 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|Other |All Version|2.041 |D2 OS/Version|Windows |All Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4313] undefined identifier error with scope guard statement
http://d.puremagic.com/issues/show_bug.cgi?id=4313
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
Version|2.041 |D1 D2
--- Comment #2 from yebblies yebbl...@gmail.com 2012-01-31 14:02:11 EST ---
(In reply to comment #1)
Seems a bit strange. According to CompoundStatement::semantic this is
rewritten
as try-catch-finally.
Even scope(exit) would have the auto res = 0 in the try block which would
result in undefined identifier.
Because the declaration is nothrow, main's body becomes:
{
int res = 0;
writeln(res);
return 0;
}
But yes, this is a bug.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4517] final switch over with base type allows missing values
http://d.puremagic.com/issues/show_bug.cgi?id=4517 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|Other |All AssignedTo|nob...@puremagic.com|yebbl...@gmail.com --- Comment #3 from yebblies yebbl...@gmail.com 2012-01-31 14:17:31 EST --- https://github.com/D-Programming-Language/dmd/pull/662 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4545] Alias to members possible without this instance
http://d.puremagic.com/issues/show_bug.cgi?id=4545 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #11 from yebblies yebbl...@gmail.com 2012-01-31 14:19:14 EST --- *** This issue has been marked as a duplicate of issue 4062 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4062] can call method without this pointer inside is()
http://d.puremagic.com/issues/show_bug.cgi?id=4062 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||tomeks...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com 2012-01-31 14:19:14 EST --- *** Issue 4545 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 4554] Cyclic constructor calls cause stack overflow
http://d.puremagic.com/issues/show_bug.cgi?id=4554 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||yebbl...@gmail.com Platform|Other |All Resolution|INVALID | OS/Version|Windows |All Severity|normal |enhancement --- Comment #3 from yebblies yebbl...@gmail.com 2012-01-31 14:21:19 EST --- I think this is worth asking for. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5178] StructLiteral should not be lvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5178 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #2 from yebblies yebbl...@gmail.com 2012-01-31 14:36:09 EST --- *** This issue has been marked as a duplicate of issue 5889 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue (it binds to ref parameters)
http://d.puremagic.com/issues/show_bug.cgi?id=5889 --- Comment #13 from yebblies yebbl...@gmail.com 2012-01-31 14:36:09 EST --- *** Issue 5178 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 6458] Multibyte char literals shouldn't implicitly convert to char
http://d.puremagic.com/issues/show_bug.cgi?id=6458 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #11 from yebblies yebbl...@gmail.com 2012-01-31 15:48:56 EST --- Actually, this doesn't involve integer range propagation. https://github.com/D-Programming-Language/dmd/pull/663 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7406] New: tuple foreach doesn't work with mixed tuples
http://d.puremagic.com/issues/show_bug.cgi?id=7406
Summary: tuple foreach doesn't work with mixed tuples
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2012-01-30 20:58:19 PST ---
template TypeTuple(T...)
{
alias T TypeTuple;
}
template foobar(T)
{
enum foobar = 2;
}
void main()
{
foreach(sym; TypeTuple!(int, double)) // OK
pragma(msg, sym.stringof);
foreach(sym; TypeTuple!(foobar)) // OK
pragma(msg, sym.stringof);
foreach(sym; TypeTuple!(main))// OK
pragma(msg, sym.stringof);
foreach(sym; TypeTuple!(int, foobar)) // Error: type int has no value
pragma(msg, sym.stringof);
foreach(sym; TypeTuple!(int, main)) // Error: type int has no value
pragma(msg, sym.stringof);
}
As soon as a symbol is part of the tuple it is treated as expression
tuple. Foreach with an expression tuple then tries to use each tuple
element as initializer which fails for types.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6497] [safeD] Can take address of local variable through ?:
http://d.puremagic.com/issues/show_bug.cgi?id=6497 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|Other |All AssignedTo|nob...@puremagic.com|yebbl...@gmail.com Summary|[safeD] Escaping a |[safeD] Can take address of |reference to a local|local variable through ?: |variable from safe function | OS/Version|Linux |All --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 16:57:04 EST --- https://github.com/D-Programming-Language/dmd/pull/664 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7407] New: Can't implicitly convert char[][] to const(char)[][]
http://d.puremagic.com/issues/show_bug.cgi?id=7407
Summary: Can't implicitly convert char[][] to const(char)[][]
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: siegelords_ab...@yahoo.com
--- Comment #0 from siegelords_ab...@yahoo.com 2012-01-30 21:58:12 PST ---
Compiling this with the latest DMD (fca8ba6f445fe99b55a6953722815c16d68344fa):
void main()
{
char[][] a;
const(char)[][] b = a;
}
Yields this error:
test.d(4): Error: cannot implicitly convert expression (a) of type char[][] to
const(char)[][]
This used to compile fine in DMD 2.057.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6564] enum with no initializer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=6564
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||yebbl...@gmail.com
Resolution||INVALID
--- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 16:59:16 EST ---
enum Length; is a forward declaration to an enum type defined elsewhere.
eg.
--- x.d ---
enum Length
{
... members ...
}
--- x.di ---
enum Length;
Not sure this is the greatest thing to allow, but it is correct according to
the spec. Please open an enhancement request to disallow forward declarations
of enums is you think this is desirable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6564] enum with no initializer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=6564 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-01-30 22:19:30 PST --- (In reply to comment #1) --- x.di --- enum Length; That's not generated by the compiler (at least not 2.057, I don't know about 2.058 HEAD). But how does it make sense to hide enum members anyway? I've never seen D code that uses a forward enum declaration. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7407] Can't implicitly convert char[][] to const(char)[][]
http://d.puremagic.com/issues/show_bug.cgi?id=7407 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||INVALID --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 17:20:42 EST --- Not a bug. See issue 4251. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6564] enum with no initializer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=6564 --- Comment #3 from yebblies yebbl...@gmail.com 2012-01-31 17:25:22 EST --- (In reply to comment #2) That's not generated by the compiler (at least not 2.057, I don't know about 2.058 HEAD). It doesn't get generated by the compiler, but you can still do it. But how does it make sense to hide enum members anyway? An enum declaration creates its own type, so in the same kind of places you'd want to pass around an opaque struct pointer. I've never seen D code that uses a forward enum declaration. Neither have I, but I've seen plenty of C/C++ source that does it. eg dmd -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6578] Ignored const with struct with constructor
http://d.puremagic.com/issues/show_bug.cgi?id=6578 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords|diagnostic |patch CC||yebbl...@gmail.com Platform|x86 |All AssignedTo|nob...@puremagic.com|yebbl...@gmail.com OS/Version|Windows |All --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 17:26:17 EST --- The devil's patch: https://github.com/D-Programming-Language/dmd/pull/666 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7408] New: traits compiles fails for built-in properties of template instances
http://d.puremagic.com/issues/show_bug.cgi?id=7408
Summary: traits compiles fails for built-in properties of
template instances
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2012-01-30 22:37:44 PST ---
template foobar()
{
}
void main()
{
pragma(msg, foobar!().stringof); // OK
static assert(__traits(compiles, foobar!().stringof)); // FAILS
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6564] enum with no initializer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=6564 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-01-30 22:38:43 PST --- (In reply to comment #3) An enum declaration creates its own type, so in the same kind of places you'd want to pass around an opaque struct pointer. Like struct Foo;, I see. I've seen opaque structs before but never opaque enums. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7403] Possible to instantiate forward referenced classes
http://d.puremagic.com/issues/show_bug.cgi?id=7403 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #1 from Jacob Carlborg d...@me.com 2012-01-30 23:20:01 PST --- Isn't it possible to have the implementation in a different object file? -- 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 #3 from github-bugzi...@puremagic.com 2012-01-30 23:22:15 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ac69d4b9893725d0eb7f40002f73d0b280214b02 Merge pull request #665 from donc/ice5796 ICE bugs 5796 and 6720 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5796] ICE with pragma(msg, ...) after missing '; ' in a template
http://d.puremagic.com/issues/show_bug.cgi?id=5796 --- Comment #1 from github-bugzi...@puremagic.com 2012-01-30 23:22:18 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ac69d4b9893725d0eb7f40002f73d0b280214b02 Merge pull request #665 from donc/ice5796 ICE bugs 5796 and 6720 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6706] 'inout' is accepted in foreach, but apparently ignored
http://d.puremagic.com/issues/show_bug.cgi?id=6706 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Platform|Other |All Resolution||WORKSFORME OS/Version|Windows |All --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 18:49:50 EST --- This doesn't compile any more. (dmd 2.058) It was probably fixed with the other inout bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6760] Disallow disabled overrides
http://d.puremagic.com/issues/show_bug.cgi?id=6760 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2012-01-31 18:52:17 EST --- Same thing for deprecated overrides. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #18 from yebblies yebbl...@gmail.com 2012-01-31 18:52:51 EST --- *** This issue has been marked as a duplicate of issue 6760 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6760] Disallow disabled overrides
http://d.puremagic.com/issues/show_bug.cgi?id=6760 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||larsi...@igesund.net --- Comment #2 from yebblies yebbl...@gmail.com 2012-01-31 18:52:51 EST --- *** Issue 1449 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: ---
