Compiling this with DDoc: enum Spork { Knife, Spoon } /// This is a function that takes a Spork as a default param. void foon(Spork s = Spork.Knife) { } Results in the rather cryptic: void foon(Spork s = cast(Spork)0); Generated for the function signature. What is a cast(Spork)0?
I believe this is fixed in the current DMD 2.026. It outputs: void foon(Spork s = (Spork).Knife); Which, although not aesthetically perfect, definitely resolves this bug. Note that this bug is not fixed in DMD 1.030. -[Unknown]
(In reply to comment #1) > Note that this bug is not fixed in DMD 1.030. Then it isn't fixed. So don't mark it as such.
(In reply to comment #1) > I believe this is fixed in the current DMD 2.026. It outputs: > > void foon(Spork s = (Spork).Knife); > > Which, although not aesthetically perfect, definitely resolves this bug. > > Note that this bug is not fixed in DMD 1.030. Not sure why you're using such an old D1 compiler (especially if you're trying to compare to the D2 compiler), but it's definitely not fixed in 1.041 either. (I can't seem to download 1.042.)
Sounds as though 1.042 is still under construction, and the changelog under construction has been inadvertently uploaded. After all, I wouldn't expect such a small documentation fix to warrant a new DMD release, especially given the number of more serious problems with the documentation.
(In reply to comment #2) > (In reply to comment #1) > > Note that this bug is not fixed in DMD 1.030. > > Then it isn't fixed. So don't mark it as such. A common convention (that I mistakenly assumed was followed here) is to mark a bug fixed when the latest version fixes it. Usually, previous branches are handled by flags, summary, whiteboard, or keyword changes. It varies. Anyway, the way it was fixed doesn't look like a trivial change, and it was already fixed only in DMD 2.x, so I doubt it's a candidate for DMD 1.x. Of course, I may be wrong. Sorry about that. -[Unknown]
D2 is not the latest version of D1.
(In reply to comment #5) > A common convention (that I mistakenly assumed was followed here) is to mark a > bug fixed when the latest version fixes it. It's a convention as long as you realise that DMD 1.x and DMD 2.x are distinct products, and so the version numbers are not in a single, common chronological order. If you look at the changelog, you'll see that 1.041 and 2.026 were even released on the same day. For a bug to be called fixed, it must be fixed in both the latest D1 compiler (versions 1.x) and the latest D2 compiler (versions 2.x). The only exception is when the nature of the bug makes it applicable only to D1 or only to D2.
Currently D1 development is focused on fixing bugs. This means that all bugs in D1 should be really fixed, not just marked as such.
Tried with dmd 1.065 and dmd 2.050, bug seems to be fixed.
https://dlang.org/library/std/process/pipe_process.html shows: ProcessPipes pipeProcess( const(char[][]) args, Redirect redirect = cast(Redirect)7, const(string[string]) env = cast(const(string[string]))null, Config config = cast(Config)0, const(char[]) workDir = null ) @safe; with cast(Redirect)7, instead of Redirect redirect = Redirect.all, as in source code
(In reply to Timothee Cour from comment #10) > https://dlang.org/library/std/process/pipe_process.html > shows: > > ProcessPipes pipeProcess( > const(char[][]) args, > Redirect redirect = cast(Redirect)7, > const(string[string]) env = cast(const(string[string]))null, > Config config = cast(Config)0, > const(char[]) workDir = null > ) @safe; > > > with > > cast(Redirect)7, > > instead of > > Redirect redirect = Redirect.all, > > as in source code what's worse is that https://issues.dlang.org/show_bug.cgi?id=9695 was marked as wontfix, making it impossible to lookup enum values for an integer Also discussed here: https://issues.dlang.org/show_bug.cgi?id=17171
(In reply to Timothee Cour from comment #10) > https://dlang.org/library/std/process/pipe_process.html > shows: > > ProcessPipes pipeProcess( > const(char[][]) args, > Redirect redirect = cast(Redirect)7, > const(string[string]) env = cast(const(string[string]))null, > Config config = cast(Config)0, > const(char[]) workDir = null > ) @safe; > > > with > > cast(Redirect)7, > > instead of > > Redirect redirect = Redirect.all, > > as in source code Interestingly, when compiling a minimal test - just the enum declarations and the pipeProcess function - the ddoc generated looks fine. --- Declaration @safe ProcessPipes pipeProcess(in char[][] args, Redirect redirect = Redirect.all, const string[string] env = null, Config config = Config.none, in char[] workDir = null); --- I think this should be closed, and other issues stemming from handled in their respective report numbers.
(In reply to Timothee Cour from comment #10) > https://dlang.org/library/std/process/pipe_process.html > shows: > > ProcessPipes pipeProcess( > const(char[][]) args, > Redirect redirect = cast(Redirect)7, > const(string[string]) env = cast(const(string[string]))null, > Config config = cast(Config)0, > const(char[]) workDir = null > ) @safe; > > > with > > cast(Redirect)7, > > instead of > > Redirect redirect = Redirect.all, > > as in source code This is a byproduct of DDOX, not DDOC. See issue 17171 comment 2. As stated in comment 9, this issue is again verified resolved in both 1.076 and 2.077.0-beta.1.
(In reply to Iain Buclaw from comment #12) > > Interestingly, when compiling a minimal test - just the enum declarations > and the pipeProcess function - the ddoc generated looks fine. > Correct, this is a DDOX issue, not DDOC. > > I think this should be closed, and other issues stemming from handled in > their respective report numbers. Will be closed in 1 week, pending feedback to issue 17171 comment2.
Ok. Thanks for the explanation.