[Issue 19605] New: enum X: "Error: enum X is forward referenced when looking for sizeof"
https://issues.dlang.org/show_bug.cgi?id=19605 Issue ID: 19605 Summary: enum X: "Error: enum X is forward referenced when looking for sizeof" Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: elpenguin...@gmail.com Very easy to reproduce: ``` enum X; static assert(X.sizeof == 0); ``` Note that I'm not exactly sure what the size of this should be. My guess was 0, but DMD 2.064 seems to manage to evaluate it to 4 despite still issuing the same error. --
[Issue 18057] [ICE] Segmentation fault (stack overflow) in Expression::ctfeInterpret()
https://issues.dlang.org/show_bug.cgi?id=18057 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/8d6d1ea638e92f85b2af9fb83c2c019e38a0afe3 testsuite: Add another test for issue 18057 https://github.com/dlang/dmd/commit/de0782f642913cabb72bc91cf4d81209f035c6e2 Merge pull request #9285 from ibuclaw/fail18057b testsuite: Add another test for issue 18057 merged-on-behalf-of: Nicholas Wilson --
[Issue 19603] [Visual D] Fresh installation VS 2017 ComEdition: Could not load File or assembly ...
https://issues.dlang.org/show_bug.cgi?id=19603 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze --- It seems that this assembly is not installed by VS unconditionally. See also https://stackoverflow.com/questions/43447112/creating-new-wix-project-in-visual-studio-2017-throws-an-error My guess is that enabling "Visual Studio Extension Development" in the VS installer might help. --
[Issue 19604] Cannot register a forked GitHub repo
https://issues.dlang.org/show_bug.cgi?id=19604 Victor Porton changed: What|Removed |Added Hardware|x86_64 |All OS|Linux |All Severity|enhancement |major --
[Issue 19604] New: Cannot register a forked GitHub repo
https://issues.dlang.org/show_bug.cgi?id=19604 Issue ID: 19604 Summary: Cannot register a forked GitHub repo Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: por...@narod.ru I am trying to register a forked GitHub repo. code.dlang.org warns me that I am about to register a forked repo (yes, that is correct). After I click "Yes", I see "Missing form field." (despite I entered the repo URL correctly) My repo: https://github.com/vporton/redland-bindings --
[Issue 16169] nWayUnion assertion failure
https://issues.dlang.org/show_bug.cgi?id=16169 Jon Degenhardt changed: What|Removed |Added CC||jrdemail2000-dl...@yahoo.co ||m --- Comment #2 from Jon Degenhardt --- The PR I am working on for issue 19532 will likely fix this as well. --
[Issue 17966] chunkBy cannot accept an input range (from multiwayMerge)
https://issues.dlang.org/show_bug.cgi?id=17966 Jon Degenhardt changed: What|Removed |Added CC||jrdemail2000-dl...@yahoo.co ||m --- Comment #4 from Jon Degenhardt --- The PR I am working on for issue 19532 will likely fix this as well. --
[Issue 19532] chunkBy assert error involving non-forward input ranges.
https://issues.dlang.org/show_bug.cgi?id=19532 --- Comment #5 from Jon Degenhardt --- It turns out that chunkBy has several issues with non-forward input ranges. I am working on a PR to address them. --
[Issue 19532] chunkBy assert error involving non-forward input ranges.
https://issues.dlang.org/show_bug.cgi?id=19532 Jon Degenhardt changed: What|Removed |Added Summary|chunkBy assert error|chunkBy assert error |involving reference input |involving non-forward input |ranges. |ranges. --
[Issue 19601] Running -profile=gc when no gc is logged leaves old misleading file contents
https://issues.dlang.org/show_bug.cgi?id=19601 --- Comment #1 from John Burton --- It looks like the reason is this line :- https://github.com/dlang/druntime/blob/424640864c2aa001731467e96f637bd3e704e481/src/rt/profilegc.d#L137 where it only creates the file if there is anything to write to it. It's not as simple as just removing the test though to "fix" as we presumably only want to do this if the user has requested the profile was made. --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 --- Comment #10 from johanenge...@weka.io --- Assuming it is intended behavior to not run dtors when an Error is thrown: The Error documentation says that "Certain runtime guarantees may fail to hold when these errors are thrown, making it unsafe to continue execution after catching them." But why "after catching" ? What makes catching so special? User code will still run in (some) dtors. I think what the text is saying is that "Certain runtime guarantees may fail to hold when these errors are thrown, making it unsafe to continue execution PERIOD." Perhaps a good solution is to simply immediately abort execution upon throwing an Error. --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 johanenge...@weka.io changed: What|Removed |Added CC||johanenge...@weka.io --- Comment #9 from johanenge...@weka.io --- Spec-wise, https://dlang.org/spec/errors.html#the_d_error_handling_solution should be changed to clearly state what is happening. Currently, it says that throwing and catching Error is good for error handling but it very clearly isn't. It's contradicting object.exception and object.error page's advice, https://dlang.org/library/object/exception.html https://dlang.org/library/object/error.html, of never catching exceptions not derived from Exception (i.e. Throwables and Errors). --
[Issue 19592] Rule for IdentifierList is wrong
https://issues.dlang.org/show_bug.cgi?id=19592 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19592] Rule for IdentifierList is wrong
https://issues.dlang.org/show_bug.cgi?id=19592 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/870cf7441e9a3e302c8fbcdca8c408786b486815 fix issue 19592 - Rule for IdentifierList is wrong https://github.com/dlang/dlang.org/commit/269a972eb1a8db6ac36d30dabb680498c5cb966c Merge pull request #2556 from Basile-z/issue-19592 fix issue 19592 - Rule for IdentifierList is wrong merged-on-behalf-of: Nicholas Wilson --
[Issue 19603] New: [Visual D] Fresh installation VS 2017 ComEdition: Could not load File or assembly ...
https://issues.dlang.org/show_bug.cgi?id=19603 Issue ID: 19603 Summary: [Visual D] Fresh installation VS 2017 ComEdition: Could not load File or assembly ... Product: D Version: D2 Hardware: All URL: http://dlang.org/ OS: All Status: NEW Severity: enhancement Priority: P3 Component: visuald Assignee: nob...@puremagic.com Reporter: marc.arnold.b...@gmail.com Created attachment 1728 --> https://issues.dlang.org/attachment.cgi?id=1728&action=edit pop up in case my key is wrong Hi, when I try to create a new D Project from Menu I can select "Visual D Win 32 Appl" but after defining a Name and "OK" I get a pop-up and it fails: Could not load file or assembly 'Microsoft.VisualStudio.TemplateWizardInterface Version=8.0.0.0, Culture=neutrak, PublicKeyToken='b03f5f7f11d50a3a or one of its dependencies. System cannot find the file specified It is a fresh VS2017 installation triggered from VisualD installer 0.48 I already rebooted => same issue. The messsage is not telling me anythinh usefull like "something wrong" google shows me that the Messagetext is used for almost everything in VS. --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 --- Comment #8 from Eyal --- (In reply to Mathias LANG from comment #6) > And that is the real bug, which is reported as 17494 That would be good for predictability. However, it makes unwinding quite useless, as opposed to a more sensible tls handler installed. --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 --- Comment #7 from Jacob Carlborg --- (In reply to Mathias LANG from comment #6) > Yep, however that's covered by the specs: > > > Individual tests are specified in the unit test using spec/expression, > > AssertExpressions. Unlike AssertExpressions used elsewhere, the assert is > > not assumed to hold, and upon assert failure the program is still in a > > defined state. > > https://dlang.org/spec/unittest.html It's difficult to know if the AssertError was thrown from a "unittest" block or from somewhere else. --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 --- Comment #6 from Mathias LANG --- (In reply to Jacob Carlborg from comment #5) > > For a unit test framework it's useful to catch AssertError to be able to > continue running other tests. Yep, however that's covered by the specs: > Individual tests are specified in the unit test using spec/expression, > AssertExpressions. Unlike AssertExpressions used elsewhere, the assert is not > assumed to hold, and upon assert failure the program is still in a defined > state. https://dlang.org/spec/unittest.html (In reply to Eyal from comment #4) > Just to clarify on my last point, if "auto sneakyThrow" is changed to "void > sneakyThrow" -- it DOES run the dtor! Because it is no longer inferred to be > nothrow. > > This is a really unpredictable semantics for a simple program, doesn't feel > at all reasonable in a language that desires safety. And that is the real bug, which is reported as 17494 --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #5 from Jacob Carlborg --- (In reply to Mathias LANG from comment #2) > There is still value in catching `Error` though: as a last resort mesure: > catch, log & abort is one thing, and catching at the top of a thread/fiber > to avoid the program termination is another. For a unit test framework it's useful to catch AssertError to be able to continue running other tests. --
