[Issue 7456] Purity strength not documented
https://d.puremagic.com/issues/show_bug.cgi?id=7456 Peter Alexander changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #2 from Peter Alexander 2014-01-11 16:16:52 PST --- (In reply to comment #1) > There is some debate as to whether they even should be. pure is defined quite > correctly in the spec. weak vs strong purity is arguably just an > implementation > detail used for optimizations. I believe that this is Don's take on it (he's > both the one who came up with strong vs weak purity and the one who updated > the > spec when pure was changed). > > Now, weak vs strong purity inevitably comes up when people get confused by why > the compiler allows what are weakly pure functions to be pure (particularly > when compared with what TDPL says - though I think that many just look at it > from a functional perspective and are confused even without having read TDPL). > So, there is arguably merit in defining them somewhere. But I believe that > Don's against it. He's mentioned before that he wants the terms to go away > entirely. Implicit conversion to immutable is only allowed with strongly pure functions, so purity strength has semantic differences, not just implementation differences. These must be documented. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11906] New: Compiler assertion when comparing function pointers
https://d.puremagic.com/issues/show_bug.cgi?id=11906
Summary: Compiler assertion when comparing function pointers
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cameron_s...@hotmail.com
--- Comment #0 from Cameron Shea 2014-01-11 15:30:04
PST ---
module main;
import std.c.windows.windows;
void main()
{
extern(Windows) HMODULE function(LPCSTR) f;
assert(f != &GetModuleHandleA);
}
> dmd -g -debug -c main.d -ofobj\Debug\main.obj
Assertion failure: '0' on line 1562 in file 'cast.c'
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11906] Compiler assertion when comparing function pointers
https://d.puremagic.com/issues/show_bug.cgi?id=11906 --- Comment #1 from Cameron Shea 2014-01-11 15:33:03 PST --- DMD32 D Compiler v2.064 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #74 from Jonathan M Davis 2014-01-11 15:16:45 PST --- > It's a bigger topic amd opinions vary. AFAIK Errors skip cleanup code, but > it's possible to catch Errors to perform minimal cleanup. According to Walter, there is no guarantee that any cleanup code is run when an Error is thrown (though I'm not sure what the spec says on the matter). However, some of the folks that believe that cleanup should be done on Errors made it so that most cleanup code _is_ run when an Error is thrown. So, unless something is changed, I believe that normally finally blocks, scope(exit), scope(failure), and destructors will all be run when an Error is thrown. Where they will get skipped is when an Error is thrown from a nothrow function, and the cleanup code is outside the nothrow function, because the caller of the nothrow function will assume that the nothrow function doesn't throw anything and optimize based on that. So, at this point, whether cleanup code is run on an Error depends on the code, and at minimum, it will never be the case that cleanup code is always run on an Error, because it won't be done for nothrow functions, or we lose the ability to optimize it based on the fact that it won't throw an exception (which is one its benefits). However, whether it will ever be changed such that cleanup code is never run for Errors is an open question and a topic of hot debate. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11905] Can't make enum of custom struct types autoincrement working
https://d.puremagic.com/issues/show_bug.cgi?id=11905 --- Comment #1 from Daniel Čejchan 2014-01-11 14:57:42 PST --- CyberShadow has made a patch that should fix this: http://dump.thecybershadow.net/88e4ac8353cebe100f9379da688829e0/opt-max-check.patch -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11857] `out` parameter breaks overload resolution
https://d.puremagic.com/issues/show_bug.cgi?id=11857 --- Comment #3 from Denis Shelomovskij 2014-01-12 01:53:22 MSK --- So do I understand correctly ICE part of the issue is considered a duplicate of issue 11822 and "This code should compile" part is considered WONTFIX? If so, where is the documentation claiming such code incorrect? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11822] `-de` switch causees ICE with `auto` return and other stuff
https://d.puremagic.com/issues/show_bug.cgi?id=11822 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright 2014-01-11 13:22:50 PST --- https://github.com/D-Programming-Language/dmd/pull/3081 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11905] New: Can't make enum of custom struct types autoincrement working
https://d.puremagic.com/issues/show_bug.cgi?id=11905 Summary: Can't make enum of custom struct types autoincrement working Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: czda...@gmail.com --- Comment #0 from Daniel Čejchan 2014-01-11 12:28:35 PST --- http://pastebin.com/cnKy8LGK Such thing causes "Error: no property 'max' for type 'enumf!ushort'" error (no error line or anything). I have tried implementing my own max using enum, static immutable variable, @property function and static @property function, either one does not work (throws "Error: no property 'max' for type 'enumf!ushort', did you mean 'max'?"). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #73 from Martin Nowak 2014-01-11 10:53:13 PST --- (In reply to comment #72) > (In reply to comment #71) > OK... so the problem is basically that we call destructors / finally blocks / > scope(exit) blocks when Errors are thrown, and those may behave in a bad way > since the program was in an indeterminate state? I imagine that it's the same > for signals on POSIX? In that case, I suppose we could handle both in the same > way: immediately print a stack trace and exit, but still provide a mechanism > for the user to customize handling of such conditions. > > I recall a discussion regarding whether thrown Errors should call finalizers > on > the stack, but I suppose it's not really clear-cut. It's a bigger topic amd opinions vary. AFAIK Errors skip cleanup code, but it's possible to catch Errors to perform minimal cleanup. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11904] Error: this cannot be interpreted at compile-time (core/time.di)
https://d.puremagic.com/issues/show_bug.cgi?id=11904 --- Comment #1 from Marco Leise 2014-01-11 09:45:34 PST --- The latest versions of GDC no longer install interface files. This error occurred for the 2.063.2 version. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11904] New: Error: this cannot be interpreted at compile-time (core/time.di)
https://d.puremagic.com/issues/show_bug.cgi?id=11904 Summary: Error: this cannot be interpreted at compile-time (core/time.di) Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: CTFE Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: marco.le...@gmx.de --- Comment #0 from Marco Leise 2014-01-11 09:23:06 PST --- I tried to compile dub with dub itself like so: dub build --compiler=gdc and got this error message: /usr/include/d/4.8.1/x86_64-pc-linux-gnu/core/time.di:224: Error: this cannot be interpreted at compile time, because it has no available source code /usr/include/d/4.8.1/std/net/curl.d:195:called from here: dur(2L) It looks like there is no clear way for the D compiler even in Phobos and druntime to figure out what source needs to stay in the .di file. Is that a systematic failure? I ask that because up to 100% of any library code could be run at compile time and CTFE only works when the source is available. In effect that means that subtle changes like changing a global variable from mutable to immutable or enum only work if Phobos is installed with full source files, which at least GDC seems to try and avoid (probably in order to speed up compilation due to the high interdependencies in Phobos modules). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11138] "real" appender missing
https://d.puremagic.com/issues/show_bug.cgi?id=11138 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #7 from Vladimir Panteleev 2014-01-11 16:47:22 EET --- For the record, IIRC from my appender performance experiments I found that extra indirection (required for a copyable ref-counted appender) has a big impact on performance. Most uses of an appender do not involve passing it around by value. Andrej linked to this bug from https://github.com/D-Programming-Language/phobos/pull/502, more discussion there and at Issue 5813. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11903] New: Internal error: backend/cgcs.c 351
https://d.puremagic.com/issues/show_bug.cgi?id=11903
Summary: Internal error: backend/cgcs.c 351
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dran...@gmail.com
--- Comment #0 from Nicolas Sicard 2014-01-11 04:50:13 PST
---
struct Foo
{
immutable(int)[] list;
}
unittest
{
enum foo = Foo([1, 2, 3]);
foo.list ~= 4;
}
ICE with DMD64 D Compiler v2.065-devel-2318831:
Internal error: backend/cgcs.c 351
May be related to https://d.puremagic.com/issues/show_bug.cgi?id=11596
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11880] Reserve the keyword "yield"
https://d.puremagic.com/issues/show_bug.cgi?id=11880 --- Comment #5 from Vladimir Panteleev 2014-01-11 14:39:01 EET --- (In reply to comment #4) > Do you have an example usage syntax (and implementation)? You posted this 5 years ago: http://forum.dlang.org/post/g7uhp6$317g$1...@digitalmars.com There are other, similar implementations. > And is it going in Phobos? I don't know of any plans for that. > What about Issue 5660 ? The same arguments apply there too. I see people posted their own coroutine implementations there as well. > This is the syntax I suggested, I think it's readable. What's the more > readable > usage syntax that you suggest? My argument is that the cost of introducing a breaking change in the language is not justified for the sake of syntax sugar. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #72 from Vladimir Panteleev 2014-01-11 14:06:23 EET --- (In reply to comment #71) > It's simply that the compiler cannot handle cleanup when every instruction > could throw. In case an asynchronous exception happens in the middle of some > statement your program is immediately in an invalid state. Continuing could > deadlock or corrupt data, much worse than a crash. OK... so the problem is basically that we call destructors / finally blocks / scope(exit) blocks when Errors are thrown, and those may behave in a bad way since the program was in an indeterminate state? I imagine that it's the same for signals on POSIX? In that case, I suppose we could handle both in the same way: immediately print a stack trace and exit, but still provide a mechanism for the user to customize handling of such conditions. I recall a discussion regarding whether thrown Errors should call finalizers on the stack, but I suppose it's not really clear-cut. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11902] DMD debuginfo doesn't seem to write classes correctly
https://d.puremagic.com/issues/show_bug.cgi?id=11902 --- Comment #4 from Rainer Schuetze 2014-01-11 01:55:01 PST --- (In reply to comment #2) > Well I think he needs to come up with something if not that, because it can't > go on not being able to inspect classes. > Do you know any workarounds? One point in Walter's favor is that VS2012 contains two debug engines, one that works with '.', but fails to display other things locals in watches. The other is the "old" engine that needs the patch (enabled by "native edit and continue"). So it seems like the bug is in the VS engine, not dmd, but that doesn't help in making it work. I don't know other workarounds. IIRC ':' doesn't work. cv2pdb has option -s to configure the '.' replacement character, so you can try some alternatives using a win32 build. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11900] Implicit cast of string literal -> char* causing ambiguous call
https://d.puremagic.com/issues/show_bug.cgi?id=11900 --- Comment #5 from Jakob Ovrum 2014-01-11 01:34:43 PST --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Well it's kinda like you say, this overload set is very common, if you > > > have a C > > > function, and you want to produce a D wrapper which receives a string and > > > calls > > > through using toStringz. > > > > The ambiguity with string literal arguments probably means it's not overly > > common at this stage, but regardless, its popularity does not justify its > > use. > > We have no obligation to make concessions to enable bad code. > > How is it a concession? It seems to me like the concession was already made to > make interacting with C functions easier. I'd say if anything, this is a bug > that stems from that decision. It complicates overloading rules. > There's nowhere else in D where a dynamic array can implicitly convert to a > pointer... why does it happen ONLY in the case of a string literal? String literals are not dynamic arrays of a particular type. They are polysemous: they can be UTF-8, UTF-16 or UTF-32 strings; to wit, there is no place in the language where implicit conversion happens between dynamic arrays of different code unit element types, either. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11902] DMD debuginfo doesn't seem to write classes correctly
https://d.puremagic.com/issues/show_bug.cgi?id=11902 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #3 from Vladimir Panteleev 2014-01-11 11:29:36 EET --- (In reply to comment #1) > The problem is that the VS debugger is confused by '.' in type names. That is > why cv2pdb translates these to '@'. Sorry if this is a dumb question, but would : or :: (as for C++) work instead? @ is an unusual character to delimit namespace path components... -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11900] Implicit cast of string literal -> char* causing ambiguous call
https://d.puremagic.com/issues/show_bug.cgi?id=11900 --- Comment #4 from Manu 2014-01-11 01:21:24 PST --- (In reply to comment #3) > (In reply to comment #2) > > Well it's kinda like you say, this overload set is very common, if you have > > a C > > function, and you want to produce a D wrapper which receives a string and > > calls > > through using toStringz. > > The ambiguity with string literal arguments probably means it's not overly > common at this stage, but regardless, its popularity does not justify its use. > We have no obligation to make concessions to enable bad code. How is it a concession? It seems to me like the concession was already made to make interacting with C functions easier. I'd say if anything, this is a bug that stems from that decision. There's nowhere else in D where a dynamic array can implicitly convert to a pointer... why does it happen ONLY in the case of a string literal? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11902] DMD debuginfo doesn't seem to write classes correctly
https://d.puremagic.com/issues/show_bug.cgi?id=11902 --- Comment #2 from Manu 2014-01-11 01:22:48 PST --- Well I think he needs to come up with something if not that, because it can't go on not being able to inspect classes. Do you know any workarounds? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11901] real win64
https://d.puremagic.com/issues/show_bug.cgi?id=11901 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze 2014-01-11 00:48:22 PST --- I guess this will be fixed by the changes to formatValue included in https://github.com/D-Programming-Language/phobos/pull/1411 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11898] void[] buffers while debugging
https://d.puremagic.com/issues/show_bug.cgi?id=11898 --- Comment #1 from Rainer Schuetze 2014-01-11 00:41:18 PST --- *** Issue 11899 has been marked as a duplicate of this issue. *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11899] void[] buffers while debugging
https://d.puremagic.com/issues/show_bug.cgi?id=11899 Rainer Schuetze changed: What|Removed |Added Status|NEW |RESOLVED CC||r.sagita...@gmx.de Resolution||DUPLICATE --- Comment #1 from Rainer Schuetze 2014-01-11 00:41:18 PST --- *** This issue has been marked as a duplicate of issue 11898 *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11898] void[] buffers while debugging
https://d.puremagic.com/issues/show_bug.cgi?id=11898 Rainer Schuetze changed: What|Removed |Added Keywords||symdeb CC||r.sagita...@gmx.de Component|DMD |VisualD --- Comment #2 from Rainer Schuetze 2014-01-11 00:44:29 PST --- I guess this is more a debugger problem that could be solved by the visualizer macros added by cv2pdb. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11902] DMD debuginfo doesn't seem to write classes correctly
https://d.puremagic.com/issues/show_bug.cgi?id=11902 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze 2014-01-11 00:39:45 PST --- The problem is that the VS debugger is confused by '.' in type names. That is why cv2pdb translates these to '@'. So far, Walter rejected the proposal to also do this translation in the Win64 debug output. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11902] New: DMD debuginfo doesn't seem to write classes correctly
https://d.puremagic.com/issues/show_bug.cgi?id=11902 Summary: DMD debuginfo doesn't seem to write classes correctly Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: turkey...@gmail.com --- Comment #0 from Manu 2014-01-11 00:22:08 PST --- DMD-Win64: While debugging in Visual Studio, inspecting classes doesn't seem to work properly. Hovering over a class instance: It shows the class pointer correctly. Clicking '+' to reveal the members shows a list with the correct number of members... But each member shows "?" as the member name, and doesn't show any value to the right, and a little red "No Entry" symbol if you hover over it. Pasting into the watch window just shows a blank line for each member. Bonus: The implicit typeinfo and vtable pointers should be present in the class too Tested with VS2010. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
