[Issue 22646] [REG2.099] CT bounds checking ignores short circuit evaluation
https://issues.dlang.org/show_bug.cgi?id=22646 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24566 --
[Issue 24566] condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22646 --
[Issue 24566] New: condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566
Issue ID: 24566
Summary: condition that starts with runtime value and uses
compile time array does not short circuit
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
If I mix a runtime and compile time expression in a condition, short circuiting
doesn't prevent a compile-time bounds check for constant folded arrays.
```d
enum a = true;
bool b = true;
enum str = "a";
if(a && str.length > 1 && str[1] == 'a') {} // ok
if(b && str.length > 1 && str[1] == 'a') {} // compiler error
if(!b && str.length > 1 && str[1] == 'a') {} // compiler error
if(str.length > 1 && b && str[1] == 'a') {} // ok
```
The error is:
Error: string index 1 is out of bounds [0 .. 1]
If the runtime condition is not first, then it compiles.
Note that even if the runtime condition is false and should short circuit the
whole thing, the compiler still errors.
As far as I can tell, this has always been the case, so not a regression.
Though a related issue might be issue 22646.
--
[Issue 24564] std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #9004 "Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of Fi…" was merged into master: - 44407884d464d60f980cb73b68a8024516ec7129 by Nick Treleaven: Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of FileException https://github.com/dlang/phobos/pull/9004 --
[Issue 24565] New: out contract variable is implicitly const
https://issues.dlang.org/show_bug.cgi?id=24565
Issue ID: 24565
Summary: out contract variable is implicitly const
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
The spec does not mention this:
https://dlang.org/spec/function.html#postconditions
struct R
{
bool empty(); // only logically const, not D const
}
R f() // returns a mutable R
out(r; r.empty) // Error: mutable method `R.empty` is not callable using a
`const` object
{
R r; // not const
return r;
}
For the above case, an `out` contract cannot be used. Note that inserting
`assert(r.empty);` before the return statement does work.
--
[Issue 24564] std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/phobos pull request #9004 "Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of Fi…" fixing this issue: - Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of FileException https://github.com/dlang/phobos/pull/9004 --
[Issue 24564] std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 johanenge...@weka.io changed: What|Removed |Added Keywords||industry --
[Issue 24564] New: std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 Issue ID: 24564 Summary: std.file.DirEntry throws Exception instead of FileException Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: major Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: johanenge...@weka.io `_ensureStatDone` and `_ensureLStatDone` use `enforce` https://github.com/dlang/phobos/blob/976dbf65566145e645f5963f76f16f7d9cb96dbf/std/file.d#L4061 (which throws an `Exception`) instead of using `cenforce` (used elsewhere in std.file, which throws `FileException`). --
[Issue 24563] Make the compiler provide a reason for why it has disabled a function
https://issues.dlang.org/show_bug.cgi?id=24563 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- The problem here is that the error is found in generated code which generally is cryptic to the user. Ideally, you would have a way to propagate the error that is found in generated code in a way that you can link the error message to actual user code. --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #16519 "Fix Bugzilla Issue 24560 - dmd crash on imported function with default parameter containing new" fixing this issue: - Fix Bugzilla Issue 24560 - dmd crash on imported function with default parameter containing new https://github.com/dlang/dmd/pull/16519 --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 RazvanN changed: What|Removed |Added Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #4 from RazvanN ---
The import is not necessary. Having the code in a single file also segfaults:
class C { }
struct S
{
static void fun(C heur = new C) { }
}
void main()
{
S.fun();
}
--
[Issue 24563] New: Make the compiler provide a reason for why it has disabled a function
https://issues.dlang.org/show_bug.cgi?id=24563 Issue ID: 24563 Summary: Make the compiler provide a reason for why it has disabled a function Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: issues.dl...@jmdavisprog.com Currently, whenever the compiler is unable to generate a function that it would normally generate for a type (e.g. a copy constructor, because it has a member variable with a copy constructor, or an opAssign, because it has a member variable with an overloaded opAssign), it seems to just mark it as @disable as if the user had explicitly written the function prototype and then marked it with @disable. The result of this is that when you try to use such an operation on a type, you get an extremely uninformative error message - e.g. from https://issues.dlang.org/show_bug.cgi?id=24562: --- q.d(36): Error: generated function `q.main.S2.opAssign` cannot be used because it is annotated with `@disable` --- It _is_ fortunately smart enough to say that it's a generated function, but it says nothing about why opAssign has been disabled. This can make it extremely difficult to figure out what the actual problem is, and I'm unaware of any way to get that information short of running the compiler through a debugger. So, please fix it so that when the compiler says that a generated function was disabled, it explains _why_ it was disabled, so that we have some hope of actually figuring out what the problem is and how to fix it. In some cases, it might be a simple fix on the programmer's part, whereas in others, it could be a compiler bug. Either way, there's no hint as to what the problem could be. The compiler has basically just said that it failed without giving an actual reason. --
