[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-04-05 23:27:20 PDT --- The second issue is not the same and isn't a regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 --- Comment #2 from github-bugzi...@puremagic.com 2012-04-05 23:28:16 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6fc972df155d69de9b001b28dc6f5a7d16faf351 fix Issue 7820 - regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 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 7833] [2.059 Beta] Changelog should clearly mention struct literal/opCmp/opEquals changes
http://d.puremagic.com/issues/show_bug.cgi?id=7833 --- Comment #3 from Nick Sabalausky cbkbbej...@mailinator.com 2012-04-06 00:10:57 PDT --- It also needs to mention this stuff in the Operator Overloading page of the documentation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7843] Regression(2.059 beta): Informational warning fails to produce executable
http://d.puremagic.com/issues/show_bug.cgi?id=7843 --- Comment #1 from github-bugzi...@puremagic.com 2012-04-06 00:28:31 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8b665514b3a1473a59cc75b0a63299d462206e86 fix Issue 7843 - Regression(2.059 beta): Informational warning fails to produce executable -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7843] Regression(2.059 beta): Informational warning fails to produce executable
http://d.puremagic.com/issues/show_bug.cgi?id=7843 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 7826] [D2 Beta] Cannot use getHash in toHash without a warning
http://d.puremagic.com/issues/show_bug.cgi?id=7826 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2012-04-06 00:35:06 PDT --- Clearly if toHash() is required to be pure, getHash() must also be. But I think it is unreasonable for the compiler to demand that toHash() be pure, especially at the present time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7826] [D2 Beta] Cannot use getHash in toHash without a warning
http://d.puremagic.com/issues/show_bug.cgi?id=7826 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2012-04-06 00:49:29 PDT --- I believe that tohash is among the functions which were decided must be @safe const pure nothrow on classes. So, in that case, I would expect it to be required (though not until Object is appropriately const-correct and whatnot). But I don't see why @safe, const, pure, or nothrow should be required for structs, since no inheritance is involved. With classes, with have to pick what we want and use that for everything (possibly with some overloads which don't have quite the same list of attributes), but structs don't have the same requirements/restrictions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7844] New: for-loop end-condition optimization
http://d.puremagic.com/issues/show_bug.cgi?id=7844
Summary: for-loop end-condition optimization
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: minas_mina1...@hotmail.co.uk
--- Comment #0 from minas_mina1...@hotmail.co.uk 2012-04-06 01:14:27 PDT ---
I have recently made a program that finds the sum of all primes (they are 11)
that truncable from left to right and from right to left.
I compiled it with -O -release -inline -noboundscheck
The results were:
real0m1.659s
user0m1.652s
sys0m0.000s
I made a few changes to make it compile as C code, and compiled in gcc with -O5
-lm -std=c99. The results:
real0m0.764s
user0m0.760s
sys0m0.004s
There's ~900 ms difference here, which is big.
The problem is in a function I used, isPrime(ulong)
/// returns true if n is a prime number
bool isPrime(ulong n)
{
// 0 and 1 aren't primes
if( n 2 ) return false;
if( n % 2 == 0 n != 2)
return false; // an even number can't be a prime (except 2)
// check only if it's odd
for(ulong i = 2; i = cast (ulong)sqrt(cast(double)n+1); ++i)
if( n % i == 0 )
return false;
return true;
}
As you can see, in the for loop, sqrt() is called in every iteration and that's
what makes it slower. When changed to:
ulong limit = cast (ulong)sqrt(cast(double)n+1)
for(ulong i = 2; i = limit; ++i)
It performs in 400ms!!!
Somehow the C version manages to do that sort of optimizations. I expect DMD to
do it as well, as it makes the code A LOT faster.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7845] New: Internal error: ../ztc/cgcs.c 354
http://d.puremagic.com/issues/show_bug.cgi?id=7845
Summary: Internal error: ../ztc/cgcs.c 354
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: maxim...@gmail.com
--- Comment #0 from Maksim Zholudev maxim...@gmail.com 2012-04-06 01:26:26
PDT ---
Code:
--
import std.stdio;
void main()
{
with(File(Vocabulary-4.txt, rt))
foreach(s; byLine) writeln(s);
}
--
DMD64 D Compiler v2.058 on 64-bit Linux output:
--
Internal error: ../ztc/cgcs.c 354
--
=== Additional information ===
The same error for:
--
...
auto f = File(Vocabulary-4.txt, rt);
with(f)
foreach(s; byLine) writeln(s);
...
--
No error for:
--
...
auto f = File(Vocabulary-4.txt, rt);
foreach(s; f.byLine) writeln(s);
...
--
On the following code it works well:
--
import std.stdio;
void main()
{
struct Foo {string s;}
with(Foo(fffuuu))
foreach(c; s)
writeln(c);
}
--
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7846] New: Forward referenced storage class is not applied in certain cases
http://d.puremagic.com/issues/show_bug.cgi?id=7846
Summary: Forward referenced storage class is not applied in
certain cases
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-04-06 02:26:03 PDT ---
static assert(is(typeof(x)==const(int))); // pass
static assert(!is(typeof({x=2;}))); // pass
pragma(msg, typeof(x)); // int
pragma(msg, is(typeof({x=2;}))); // true
const int x;
pragma(msg, typeof(x)); // const(int)
pragma(msg, is(typeof({x=2;}))); // false
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 --- Comment #3 from timon.g...@gmx.ch 2012-04-06 02:26:40 PDT --- (In reply to comment #1) The second issue is not the same and isn't a regression. OK. Reposted as issue 7846. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 --- Comment #4 from timon.g...@gmx.ch 2012-04-06 02:40:25 PDT --- The code this was reduced from still does not compile with -property for the same reason. I will try to create another reduced example and then reopen the issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820
timon.g...@gmx.ch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #5 from timon.g...@gmx.ch 2012-04-06 04:33:19 PDT ---
These snippets still expose the buggy behavior even after the fix:
---
int[] array;
pragma(msg, typeof(array.front));
@property int front(int[] a){return a[0];}
---
---
import std.algorithm;
alias find!(a == b,int[],int) test;
---
I assume it is the same bug in both cases.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7102] std.numeric.gcd with BigInts too
http://d.puremagic.com/issues/show_bug.cgi?id=7102 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #3 from bearophile_h...@eml.cc 2012-04-06 05:11:00 PDT --- Instead of opening a new enhancement request, I reopen this one, because the request is essentially the same. I suggest to add this bignum specialization to std.numeric.gcd (or add a GCD in std.bigint, but I'd like to have a single function for both bigints and built-in ints). Even if this isn't the fastest multi-precision GCD algorithm of the world, it seems better than not being able to compute GCD on bigints, and it looks short, both the Python prototype and the C patch are not long. http://en.wikipedia.org/wiki/Lehmer%27s_GCD_algorithm http://bugs.python.org/issue1682 http://bugs.python.org/file9464/lehmer_gcd.py http://bugs.python.org/file9486/lehmer_gcd.patch See also Issue 4125 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7835] Ignored break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835
Dmitry Olshansky dmitry.o...@gmail.com changed:
What|Removed |Added
CC||dmitry.o...@gmail.com
--- Comment #1 from Dmitry Olshansky dmitry.o...@gmail.com 2012-04-06
07:15:55 PDT ---
(In reply to comment #0)
This D2 program compiles with no warnings or errors with DMD 2.059beta:
import core.stdc.stdio: printf;
template TypeTuple(TList...) {
alias TList TypeTuple;
}
void main() {
char c = 'b';
L_MySwitch:
switch (c) {
case 'a': printf(1 a\n); break;
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break L_MySwitch;
}
default: printf(default);
}
}
For these cases I recommend to use labeled breaks
so that it's more clear for humans and compiler alike.
But it runs in a wrong way, as you see:
...dmd -run test.d
2 b
default
...dmd -w -run test.d
test.d(12): Error: switch case fallthrough - use 'goto default;' if intended
So the break inside the static foreach is ignored.
(This idiom of using a static foreach inside a switch is handy to generate
switch cases.)
Note: adding a second break, like this, doesn't improve the situation:
import core.stdc.stdio: printf;
template TypeTuple(TList...) {
alias TList TypeTuple;
}
void main() {
char c = 'b';
switch (c) {
case 'a': printf(1 a\n); break;
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break; break;
}
default: printf(default);
}
}
It can't help because the second break is by definition unreachable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7835] Ignored break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835 timon.g...@gmx.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||timon.g...@gmx.ch Resolution||INVALID --- Comment #2 from timon.g...@gmx.ch 2012-04-06 07:38:55 PDT --- Not a bug. break applies to the innermost statement that can be broken out from. This includes foreach. (I use this idiom often. Use labeled break to break from the switch.) Please reopen as enhancement if you think the code should be illegal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7765] Cannot access __gshared function pointers from static methods
http://d.puremagic.com/issues/show_bug.cgi?id=7765
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-04-06
09:41:02 PDT ---
(In reply to comment #1)
c_func() is a function, not a function pointer nor a variable, and so
__gshared
has no effect on it.
Not a bug.
Ok. But why is 'static' required? This won't work:
class Foo
{
static int test()
{
return c_func();
}
extern(C) int c_func();
}
test.d(5): Error: need 'this' to access member c_func
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7838] Give some error messages for wrong ranges
http://d.puremagic.com/issues/show_bug.cgi?id=7838
--- Comment #2 from bearophile_h...@eml.cc 2012-04-06 10:09:17 PDT ---
(In reply to comment #1)
My understanding is that you would usually put a static assert with
isInputRange, or a more specific template from std.range immediately after the
struct.
This is an example program:
import std.range, std.bigint;
struct Powers {
int m;
BigInt n;
this(int m_) { this.m = m_; }
const bool empty = false;
BigInt front() { return n ^^ m; }
void popFront() { n += 1; }
}
static assert(isInputRange!Powers);
void main() {}
If I compile it with DMD 2.059beta:
...dmd -property -run temp.d
temp.d(10): Error: static assert (isInputRange!(Powers)) is false
So it gives me no hint where the problem is. A built-in error message is
supposed to be more precise.
As alternative, maybe there is a way to add focused error messages inside a
isInputRangeVerify template to be used to verify that an input range is
correct, that uses pragma(msg) or better ctWriteln.
How is DMD supposed to know that that struct is suppose to be a range
otherwise?
I see, it's a problem.
So here we are talking more about a probabilistic compiler tip. If the
class/struct contains a popFront and front and empty methods then the
programmer probably meants it to be a range.
Thank you for your answer.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7835] Ignored break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835 --- Comment #3 from bearophile_h...@eml.cc 2012-04-06 10:06:56 PDT --- (In reply to comment #2) Not a bug. break applies to the innermost statement that can be broken out from. This includes foreach. (I use this idiom often. Use labeled break to break from the switch.) You are right, thank you. (My error was to think that static foreach doesn't support break.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7835] switch case fallthrough error despite a break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835
bearophile_h...@eml.cc changed:
What|Removed |Added
Keywords|wrong-code |diagnostic
Status|RESOLVED|REOPENED
Resolution|INVALID |
Summary|Ignored break inside static |switch case fallthrough
|foreach |error despite a break
||inside static foreach
--- Comment #4 from bearophile_h...@eml.cc 2012-04-06 10:18:05 PDT ---
Reopened, because you have missed the error message in my bug report.
Using a labeled break:
import core.stdc.stdio: printf;
template TypeTuple(TList...) {
alias TList TypeTuple;
}
void main() {
char c = 'b';
MySwitch: switch (c) {
case 'a': printf(1 a\n); break;
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break MySwitch;
}
default: printf(default);
}
}
DMD 2.059 beta gives (compiling with -w):
test.d(12): Error: switch case fallthrough - use 'goto default;' if intended
I have also changed the issue title to better reflect the problem, now the
Keywords is 'diagnostic' because it's giving a warning where there is nothing
to warn against.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7838] Give some error messages for wrong ranges
http://d.puremagic.com/issues/show_bug.cgi?id=7838 --- Comment #3 from Matt Peterson revcompg...@gmail.com 2012-04-06 10:47:21 PDT --- Yeah, I think the best solution is to add verifyInputRange etc. templates to std.range, where each criteria is checked by a separate static assert. It's just a little ugly because there will end up being nearly duplicate templates for all the different range types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7838] Give some error messages for wrong ranges
http://d.puremagic.com/issues/show_bug.cgi?id=7838 --- Comment #4 from bearophile_h...@eml.cc 2012-04-06 11:06:31 PDT --- (In reply to comment #3) It's just a little ugly because there will end up being nearly duplicate templates for all the different range types. I think putting such test code inside DMD itself doesn't reduce the overall complexity a lot... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7835] switch case fallthrough error despite a break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835
--- Comment #5 from bearophile_h...@eml.cc 2012-04-06 11:32:39 PDT ---
This compiles with no warnings and it seems to work correctly, but I don't
fully understand it:
import core.stdc.stdio: printf;
template TypeTuple(TList...) {
alias TList TypeTuple;
}
void main() {
char c = 'b';
MySwitch: switch (c) {
case 'a': printf(1 a\n); break;
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break;
}
break;
default: printf(default);
}
}
Is it correct? if the break inside here is meant to be the foreach break:
{ case o: printf(2 %c\n, c); break; }
Then why a single break is enough after:
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break;
}
break;
despite the foreach synthesizes more than one switch case?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7835] switch case fallthrough error despite a break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835
--- Comment #6 from Dmitry Olshansky dmitry.o...@gmail.com 2012-04-06
11:37:01 PDT ---
(In reply to comment #5)
This compiles with no warnings and it seems to work correctly, but I don't
fully understand it:
import core.stdc.stdio: printf;
template TypeTuple(TList...) {
alias TList TypeTuple;
}
void main() {
char c = 'b';
MySwitch: switch (c) {
case 'a': printf(1 a\n); break;
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break;
}
break;
default: printf(default);
}
}
Is it correct? if the break inside here is meant to be the foreach break:
Yes.
{ case o: printf(2 %c\n, c); break; }
No it's {case 0: printf(2 %c\n, c); }
the break did his job already, it can't work twice.
Then why a single break is enough after:
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break;
}
Then the code below gives you one break after that statement.
break;
despite the foreach synthesizes more than one switch case?
foreach synthesizes exactly one statement here.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7835] switch case fallthrough error despite a break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835
--- Comment #7 from timon.g...@gmx.ch 2012-04-06 11:41:49 PDT ---
(In reply to comment #5)
This compiles with no warnings and it seems to work correctly, but I don't
fully understand it:
import core.stdc.stdio: printf;
template TypeTuple(TList...) {
alias TList TypeTuple;
}
void main() {
char c = 'b';
MySwitch: switch (c) {
case 'a': printf(1 a\n); break;
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break;
}
break;
default: printf(default);
}
}
Is it correct? if the break inside here is meant to be the foreach break:
{ case o: printf(2 %c\n, c); break; }
Then why a single break is enough after:
foreach (o; TypeTuple!('b', 'c')) {
case o: printf(2 %c\n, c); break;
}
break;
despite the foreach synthesizes more than one switch case?
Your code is expanded to:
void main() {
char c = 'b';
switch (c) {
case 'a': printf(1 a\n); break;
{case 'b': printf(2 %c\n, c); goto break_foreach;}
{case 'c': printf(2 %c\n, c); goto break_foreach;}
break_foreach: break;
default: printf(default);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7844] implement loop invariant code motion for pure functions
http://d.puremagic.com/issues/show_bug.cgi?id=7844 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch Summary|for-loop end-condition |implement loop invariant |optimization|code motion for pure ||functions --- Comment #1 from timon.g...@gmx.ch 2012-04-06 12:52:59 PDT --- This optimization is called loop invariant code motion. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7835] switch case fallthrough error despite a break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||INVALID
--- Comment #8 from bearophile_h...@eml.cc 2012-04-06 13:12:01 PDT ---
(In reply to comment #7)
Your code is expanded to:
void main() {
char c = 'b';
switch (c) {
case 'a': printf(1 a\n); break;
{case 'b': printf(2 %c\n, c); goto break_foreach;}
{case 'c': printf(2 %c\n, c); goto break_foreach;}
break_foreach: break;
default: printf(default);
}
}
Thank you again Timon :-) So there is no bug here.
This was not easy to understand for me. (Maybe D newbies will enjoy to read an
example of this in some D tipstrickls somewhere, or maybe it was just a
conceptualization problem of mine.)
Issue closed again, as invalid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7823] Can't use a struct initializer to initialize a nested enum used as a default function argument initializer
http://d.puremagic.com/issues/show_bug.cgi?id=7823 --- Comment #2 from github-bugzi...@puremagic.com 2012-04-06 13:29:28 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b548a3d7a9c8e8999fd94e22d24c6d7a185101e4 fix Issue 7823 - Can't use a struct initializer to initialize a nested enum used as a default function argument initializer -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7823] Can't use a struct initializer to initialize a nested enum used as a default function argument initializer
http://d.puremagic.com/issues/show_bug.cgi?id=7823 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 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 --- Comment #6 from github-bugzi...@puremagic.com 2012-04-06 14:54:52 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/37c1856876382d820372dec621c46e884e5c97ab fix Issue 7820 - regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7820] regression(DMD 2.059head) Wrong error on forward reference to 'front' with -property switch
http://d.puremagic.com/issues/show_bug.cgi?id=7820 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 7847] New: [ICE] Internal error: e2ir.c 688
http://d.puremagic.com/issues/show_bug.cgi?id=7847
Summary: [ICE] Internal error: e2ir.c 688
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-04-06 15:07:28 PDT ---
DMD 2.058/DMD 2.059head
---
Bar New(T,A...)(A args){return null;}
class Bar{
this(Foo){ }
static Bar create(){
return New!Bar(Foo(0));
}
}
struct Foo{
int x;
this(T)(T ){void function() foo = {Bar.create();};}
void bar(){Foo r=Foo();}
}
---
---
Internal error: e2ir.c 688
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7847] [ICE] Internal error: e2ir.c 688 with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7847 timon.g...@gmx.ch changed: What|Removed |Added Summary|[ICE] Internal error: |[ICE] Internal error: |e2ir.c 688 |e2ir.c 688 with -inline --- Comment #1 from timon.g...@gmx.ch 2012-04-06 15:08:30 PDT --- The -inline switch is necessary to trigger the bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7847] [ICE] Internal error: e2ir.c 688 with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7847
--- Comment #2 from timon.g...@gmx.ch 2012-04-06 15:09:26 PDT ---
The following variation crashes the compiler with a segmentation fault:
Bar New(T)(Foo args){return null;}
class Bar{
this(Foo){ }
static Bar create(){
return New!Bar(Foo(0));
}
}
struct Foo{
int x;
this(T)(T ){void function() foo = {Bar.create();};}
void bar(){Foo r=Foo();}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7835] switch case fallthrough error despite a break inside static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7835 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||bra...@puremagic.com Resolution|INVALID | --- Comment #9 from Brad Roberts bra...@puremagic.com 2012-04-06 15:11:51 PDT --- I think that the expansion of the static foreach is wrong. It explains the behavior, but doesn't excuse it. I think the bug report is valid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7847] [ICE] Internal error: e2ir.c 688 with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7847
--- Comment #3 from timon.g...@gmx.ch 2012-04-06 15:16:41 PDT ---
The following variation causes an ICE in a different location:
---
Bar New(T,A...)(A args){return null;}
class Bar{
this(Foo){ }
static Bar create(){
return New!Bar(Foo(0)).foo();
}
Bar foo(){return this;}
}
struct Foo{
int x;
this(T)(T ){void function() foo = {Bar.create();};}
void bar(){Foo r=Foo();}
}
---
---
Internal error: e2ir.c 3500
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7826] [D2 Beta] Cannot use getHash in toHash without a warning
http://d.puremagic.com/issues/show_bug.cgi?id=7826 --- Comment #4 from github-bugzi...@puremagic.com 2012-04-06 17:10:03 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c324826ab425da4d2896b2d7abd97ebffcc0231b fix Issue 7826 - [D2 Beta] Cannot use getHash in toHash without a warning -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7826] [D2 Beta] Cannot use getHash in toHash without a warning
http://d.puremagic.com/issues/show_bug.cgi?id=7826 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 7848] New: pure doesn't work on unittest blocks
http://d.puremagic.com/issues/show_bug.cgi?id=7848
Summary: pure doesn't work on unittest blocks
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-04-06 22:43:59
PDT ---
This code compiles when it shouldn't:
void main()
{
}
void func()
{
}
pure unittest
{
func();
}
func is impure and should cause the compilation of the unittest block to fail.
It fails if you mark it as @safe (since func is @system), but it doesn't fail
for pure.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
