[Issue 8936] Throwing results in searching the whole directory tree rooted in current directory
http://d.puremagic.com/issues/show_bug.cgi?id=8936 David Held d...@wyntrmute.com changed: What|Removed |Added CC||d...@wyntrmute.com --- Comment #8 from David Held d...@wyntrmute.com 2012-11-22 02:54:27 PST --- The root cause is that druntime/core/sys/windows/stacktrace.d::static this() calls WinAPI's SymInitialize() with a NULL user path. This results in the default path: %CWD%;%_NT_SYMBOL_PATH%;%_NT_ALTERNATE_SYMBOL_PATH% as per the MSDN documentation here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681351%28v=vs.85%29.aspx. Unfortunately, I cannot repro this behavior on Windows 7 Home Premium SP1, dbghelp.dll 6.1. I suspect that newer versions of dbghelp.dll are simply more clever than what MSDN states (for instance, if the semantics were changed to make the default path start with the image location, 99% of all directory scanning would be eliminated; also, it is pretty silly to not have this as the default behavior). Please report which version of dbghelp.dll you are using. There are likely multiple versions present on your machine, so you can discover the one being used via 'where': where dbghelp.dll It will most likely discover the version in %SystemRoot%\system32. You can find the version in the file properties. Assuming that this is truly only a problem with older versions of dbghelp.dll (e.g.: 5.x versions), it is not difficult to simply provide a custom user path starting with the current executable image path. However, I do not have a means to verify the fix, as I cannot repro the actual problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3449] const and invariant struct members do not behave according to spec
http://d.puremagic.com/issues/show_bug.cgi?id=3449 --- Comment #18 from github-bugzi...@puremagic.com 2012-11-22 03:30:39 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/245274b4083cfc26e45111673b6264151f29abbe Merge pull request #965 from 9rnsr/fix3449 Supplemental fix for Issue 3449 - Stop fwdref by the immutable field -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9055] Compiler bails out on initializing a variable
http://d.puremagic.com/issues/show_bug.cgi?id=9055
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2012-11-22 04:21:03 PST ---
Is this a valid reduction of your code?
class Foo {
int bar() {
return 0;
}
int x = bar();
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9055] Compiler bails out on initializing a variable
http://d.puremagic.com/issues/show_bug.cgi?id=9055 Manfred Nowak svv1...@hotmail.com changed: What|Removed |Added Attachment #1164|application/octet-stream|text/plain mime type|| -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9055] Compiler bails out on initializing a variable
http://d.puremagic.com/issues/show_bug.cgi?id=9055 --- Comment #2 from Manfred Nowak svv1...@hotmail.com 2012-11-22 04:42:51 PST --- My text seems to be lost. Retry: On compiling with `-debug' dmd 2.060 evokes an exception on winXp x86 with all updates. Without `-debug', i.e without initializing the variable, no com�laints. -manfred -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9055] Compiler bails out on initializing a variable
http://d.puremagic.com/issues/show_bug.cgi?id=9055
--- Comment #3 from Manfred Nowak svv1...@hotmail.com 2012-11-22 05:09:15 PST
---
(In reply to comment #1)
Is this a valid reduction of your code?
int bar() {
int x = bar();
Not at first glance.
1)
In your code the missing `this' is declared as the root of the bug report. In
my code `this' is present.
2)
In your code reversing the lexical sequence of call and declaration does not
change the error message. In my code reversing eliminates the bailing out. In
addition no error is reported.
-manfred
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5893] Allow simple aliases for operator overloading
http://d.puremagic.com/issues/show_bug.cgi?id=5893 --- Comment #4 from github-bugzi...@puremagic.com 2012-11-22 06:24:01 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8bc59cfe8e6896435f20ce1e9bdcc226942f59a8 fix Issue 5893 - Allow simple aliases for operator overloading https://github.com/D-Programming-Language/dmd/commit/2888ec45218e2e49048e9f96be2fa0481dc00e31 Merge pull request #989 from 9rnsr/fix5893 Issue 5893 - Allow simple aliases for operator overloading -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9056] New: More precise error messages when function arguments are wrong
http://d.puremagic.com/issues/show_bug.cgi?id=9056
Summary: More precise error messages when function arguments
are wrong
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-22 14:06:08 PST ---
This is wrong code (it's not meaningful code because it's a full reduction of a
much longer program):
struct Foo {}
void bar(in Foo* f4,
in ref Foo f5,
in uint m,
ref const(Foo)* f6,
ref double x,
ref uint n) {}
void main() {
Foo f1;
Foo* f2, f3;
double x = 0;
uint n = 0;
bar(f2, f1, 0, f3, x, n);
}
DMD 2.061alpha gives:
test.d(13): Error: function test.bar (const(Foo*) f4, ref const(Foo) f5,
const(uint) m, ref const(Foo)* f6, ref double x, ref uint n) is not callable
using argument types (Foo*,Foo,int,Foo*,double,uint)
The function bar() has six arguments. Generally it's better to avoid writing
functions with six arguments, especially in languages that don't have named
arguments, but once in a while this happens. In bar() the arguments are tagged
in various complex ways. Given such error message it is not immediate to see
that this is a good way to fix the code:
struct Foo {}
void bar(in Foo* f4,
in ref Foo f5,
in uint m,
ref const(Foo)* f6,
ref double x,
ref uint n) {}
void main() {
Foo f1;
Foo* f2;
const(Foo)* f3;
double x = 0;
uint n = 0;
bar(f2, f1, 0, f3, x, n);
}
Probably during the compilation the type system of the D compiler has more
information. So in my opinion here the compiler should give a more precise
error message, that tells what arguments are not acceptable.
In this case the problem is just in the f6 argument of bar(). So I suggest an
error message similar to (or better):
test.d(13): Error: function test.bar(const(Foo*) f4, ref const(Foo) f5,
const(uint) m, ref const(Foo)* f6, ref double x, ref uint n) is not callable
using argument types (Foo*,Foo,int,Foo*,double,uint). The incompatible
arguments are: f6.
(Even better is to explain why they are not compatible, but this probably is
too much complex to do, so it's better leave this to a future enhancement
request.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
CTFE Memory Hogging Workaround?
One of the reasons I chose to use D for my project is that I was very excited about the prospect of using CTFE in mixin code. Unfortunately, there seems to be one (or several?) bugs causing CTFE to be very slow and to hog a huge amount of memory (multiple gigs of RAM and swap). Is there some known fix for this? I need this to work now. Otherwise, I'm going to have to rewrite my CTFE/mixin code in Python or something, which would be a shame, and a waste of time on my part.
[Issue 8996] [ICE](e2ir.c line 768) with bigint main-imported
http://d.puremagic.com/issues/show_bug.cgi?id=8996 --- Comment #2 from bearophile_h...@eml.cc 2012-11-22 14:21:06 PST --- The problem is not gone, but it's a little less big. Instead of reopening this, I have moved it the new Issue 9057 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9057] New: Non-constant expression error in biguintcore
http://d.puremagic.com/issues/show_bug.cgi?id=9057
Summary: Non-constant expression error in biguintcore
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-22 14:20:52 PST ---
(This is derived from Issue 8996 )
import std.typecons;
Tuple!T foo(T)(T x) {
return tuple(x);
}
void main() {
import std.bigint;
foo(BigInt(1));
}
DMD 2.061alpha gives:
...\dmd2\src\phobos\std\internal\math\biguintcore.d(92): Error: non-constant
expression ZERO
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: CTFE Memory Hogging Workaround?
Maxime Chevalier: One of the reasons I chose to use D for my project is that I was very excited about the prospect of using CTFE in mixin code. Unfortunately, there seems to be one (or several?) bugs causing CTFE to be very slow and to hog a huge amount of memory (multiple gigs of RAM and swap). Is there some known fix for this? I need this to work now. Otherwise, I'm going to have to rewrite my CTFE/mixin code in Python or something, which would be a shame, and a waste of time on my part. Please use D.learn newsgroup for similar questions, this group is not for discussions. There are coding strategies to partially reduce the memory used during CTFE, but in general it uses lot of memory, sometimes too much. This problem is well known and Don is working on it and he has improved the situation a little, but it will take time to fix it well, possibly some months or more. Currently CTFE is not fit for heavy computations. Bye, bearophile
[Issue 9058] Problem with std.traits.EnumMembers conversion to array
http://d.puremagic.com/issues/show_bug.cgi?id=9058
--- Comment #1 from bearophile_h...@eml.cc 2012-11-22 14:49:49 PST ---
While now this code gives:
import std.traits: EnumMembers;
enum Foo { A, B }
void main() {
EnumMembers[] array = [EnumMembers!Foo];
}
test.d(4): Error: template std.traits.EnumMembers(E) if (is(E == enum)) is
used
as a type
Please ignore this second test case, it's wrong (the array should be Foo[], and
it compiles correctly).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9058] New: Problem with std.traits.EnumMembers conversion to array
http://d.puremagic.com/issues/show_bug.cgi?id=9058
Summary: Problem with std.traits.EnumMembers conversion to
array
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-22 14:46:47 PST ---
import std.traits: EnumMembers;
enum Foo { A, B }
size_t bar(size_t n) {
return 0;
}
void main() {
Foo x = [EnumMembers!Foo][bar($)];
}
That code compiles and runs correctly with DMD 2.060, but with DMD 2.061alpha
gives:
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test.obj(test)
Error 42: Symbol Undefined _D4test4mainFZv8__dollark
While now this code gives:
import std.traits: EnumMembers;
enum Foo { A, B }
void main() {
EnumMembers[] array = [EnumMembers!Foo];
}
test.d(4): Error: template std.traits.EnumMembers(E) if (is(E == enum)) is used
as a type
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: CTFE Memory Hogging Workaround?
On Thursday, November 22, 2012 23:07:54 Maxime Chevalier wrote: [snip] Please do not post to this list. Only bugzilla is supposed to send messages to it (I don't even know why posting is enabled for anyone else). You subscribe to it if you want to receive all of those messages from bugzilla. If you have a bug, please report it at http://d.puremagic.com/issues If you have a question, please ask it in the D.Learn newsgroup. I'm sure that there will be people ready and willing to help you there. - Jonathan M Davis
[Issue 9059] New: No exception runtime error message with missing file + byLine
http://d.puremagic.com/issues/show_bug.cgi?id=9059
Summary: No exception runtime error message with missing file +
byLine
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-22 15:46:02 PST ---
import std.stdio: File;
void main() {
auto f = File(missing).byLine();
}
If I compile and run this program with dmd 2.061alpha with -g it correctly
gives a stack trace (with no line numbers):
dmd -g -run test.d
std.exception.ErrnoException@std\stdio.d(315): Cannot open file `missing' in
mode `rb' (No such file or direct
ory)
0x00412F44 in char[][] core.sys.windows.stacktrace.StackTrace.trace()
0x00412DCF in core.sys.windows.stacktrace.StackTrace
core.sys.windows.stacktrace.StackTrace.__ctor()
0x00404D2F in
D3std9exception80__T12errnoEnforceTPOS4core4Çâ¬c5Ôio6_+bufVAyaa11_7374645c²696f2e¨Vk315ZÇÄ-FÇÜ-L
Çâ-ZÇ܃
0x004045DC in extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).void runMa
in()
0x00404612 in extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).void runAl
l()
0x00404229 in _d_run_main
0x00402D04 in main
0x7782D309 in BaseThreadInitThunk
0x77A51603 in RtlInitializeExceptionChain
0x77A515D6 in RtlInitializeExceptionChain
If I compile and run it without -g (dmd -run test.d) it doesn't show the
std.exception.ErrnoException, and the program just crashes with no error
messages at run-time.
Maybe this is a regression.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9060] New: std.range.chain and std.range.zip cannot get frame pointer
http://d.puremagic.com/issues/show_bug.cgi?id=9060
Summary: std.range.chain and std.range.zip cannot get frame
pointer
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-22 16:00:27 PST ---
import std.algorithm: map;
import std.range: chain, zip;
void main() {
auto r = map!(x = 0)([1]);
chain(r, r);
zip(r, r);
}
DMD 2.061alpha gives:
...\dmd2\src\phobos\std\range.d(1988): Error: function
std.range.chain!(MapResult!(__lambda2, int[]),MapResult!(__lambda2,
int[])).chain.Result.save cannot get frame pointer to main
...\dmd2\src\phobos\std\range.d(1988): Error: function
std.range.chain!(MapResult!(__lambda2, int[]),MapResult!(__lambda2,
int[])).chain.Result.save cannot get frame pointer to main
...\dmd2\src\phobos\std\range.d(3792): Error: function
std.range.Zip!(MapResult!(__lambda2, int[]), MapResult!(__lambda2,
int[])).Zip.save cannot get frame pointer to main
...\dmd2\src\phobos\std\range.d(3792): Error: function
std.range.Zip!(MapResult!(__lambda2, int[]), MapResult!(__lambda2,
int[])).Zip.save cannot get frame pointer to main
This code compiles and runs correctly in DMD 2.060.
Additional problem: the error messages refer only to the locations inside chain
and zip, with no references to the call lines in main().
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9061] New: BigInt | BigInt, BigInt int
http://d.puremagic.com/issues/show_bug.cgi?id=9061
Summary: BigInt | BigInt, BigInt int
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-22 16:29:26 PST ---
Two missing BigInt operations:
import std.bigint: BigInt;
void main() {
auto x = BigInt(1) | BigInt(1);
auto y = BigInt(1) 1;
}
Those operations are used in a Binary GCD:
http://en.wikipedia.org/wiki/Binary_GCD_algorithm#Iterative_version_in_C
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9062] New: AddrExp should distinguish the existence of property resolution.
http://d.puremagic.com/issues/show_bug.cgi?id=9062
Summary: AddrExp should distinguish the existence of property
resolution.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-11-22 19:31:04 PST ---
In this case, p is an address of g, or function pointer to foo?
int g;
@property ref int foo() { return g; }
auto p = foo;
Until now, foo always returns function pointer. If we want to get g, we could
write as like:
auto p = foo(); // call foo first, then get an address of return value
But, if @property would be implemented more strictly, the syntax foo() will be
disallowed. In other words, getting g from foo will be impossible. It is a
serious flaw.
To resolve the problem, I'd like to propose a small special syntax: (foo).
If AddrExp has a parenthesized expression, a property function in the operand
will be resolved to property call.
pragma(msg, typeof( foo )); // will print int function() @property ref
pragma(msg, typeof( (foo) )); // will print int*
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9063] New: static assert should resolve property function call
http://d.puremagic.com/issues/show_bug.cgi?id=9063
Summary: static assert should resolve property function call
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-11-22 19:50:11 PST ---
These code should work.
@property bool foo(){ return true; }
static assert(foo); // should pass assertion
@property string bar() { return msg; }
static assert(false, bar); // should print msg
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9063] static assert should resolve property function call
http://d.puremagic.com/issues/show_bug.cgi?id=9063 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-11-22 20:07:21 PST --- https://github.com/D-Programming-Language/dmd/pull/1309 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9062] AddrExp should distinguish the existence of property resolution.
http://d.puremagic.com/issues/show_bug.cgi?id=9062 --- Comment #1 from github-bugzi...@puremagic.com 2012-11-22 22:24:20 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/2897ca8807d6ab54fc2c983325104b96d1bda10e fix Issue 9062 - AddrExp should distinguish the existence of property resolution https://github.com/D-Programming-Language/phobos/commit/1ce5ca470a4520d1c3956e14ec3e8dfb4fcd907f Merge pull request #966 from 9rnsr/fix9062 Supplemental fix for Issue 9062 - AddrExp should distinguish the existence of property resolution -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
