[Issue 20781] Can call @live function without checking dip1021 rules
https://issues.dlang.org/show_bug.cgi?id=20781 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #11071 "fix Issue 20781 - Can call @live function without checking dip1021 rules" was merged into master: - 62ea7b3ddb6710007b2d0b1c36502fe755a452a1 by Walter Bright: fix Issue 20781 - Can call @live function without checking dip1021 rules https://github.com/dlang/dmd/pull/11071 --
[Issue 16603] [Lexical] comment definition is incorrrect
https://issues.dlang.org/show_bug.cgi?id=16603 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- The grammar is correct and the spec states: "Block comments can span multiple lines, but do not nest." This should suffice. --
[Issue 23675] Error on direct double.NaN comparison
https://issues.dlang.org/show_bug.cgi?id=23675 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 23387] ImportC: identical structs defined in two C files lead to duplicate .init symbol on macOS
https://issues.dlang.org/show_bug.cgi?id=23387 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #14541 "fix Issue 23387 - ImportC: identical structs defined in two C files l…" was merged into master: - 7fe0aee2a4ed8775e8f55e02d2ca6696cf30ef43 by Walter Bright: fix Issue 23387 - ImportC: identical structs defined in two C files lead to duplicate .init symbol on macOS https://github.com/dlang/dmd/pull/14541 --
[Issue 23675] New: Error on direct double.NaN comparison
https://issues.dlang.org/show_bug.cgi?id=23675
Issue ID: 23675
Summary: Error on direct double.NaN comparison
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
The following code compiles without error or warning:
```d
void main()
{
double x;
alias D = double;
if (x == double.nan){} // 1 should be an error
if (x != double()){} // 2 should be an error
if (x is double.nan){} // 3 no error
if (x < (D.nan)){} // 4 should be an error
if (x == D()){}// 5 no error
if (x == double.init){}// 6 should be an error
if (x == D.init){} // 7 no error
auto vnan = double.nan;
immutable inan = double.nan;
enum enan = double.nan;
alias anan = double.nan;
if (x == vnan){} // no error
if (x == inan){} // no error
if (x == enan){} // no error
if (x == anan){} // no error
}
```
Suggestion: The comparison of a runtime floating-point expression with one of
the compile-time constant `nan` properties of the floating-point types should
be an error.
The assumption is that the programmer wanted to test if `x` holds a NaN value,
but the check is an always-false condition (in the case of `!=` an always-true
condition).
As you can see, relevant is the direct mentioning of the property, the
mentioning of the type is irrelevant, except in the default-construction/init
case. In the default-construction/init case, the type must be syntactically a
floating-point `FundamentalType` (optionally qualified). An alias to a
floating-point is syntactically not a FundamentalType, but an identifier. When
the type is syntactically an identifier that only happens to refer to
floating-point type semantically, for the default-construction/init case, there
could still be a warning, but an error would be a problem for meta-programming.
The error message should suggest to use `std.math.traits.isNaN` (first and
second example) or `std.math.operations.cmp` (fourth example).
Maybe the error message could suggest using `is` if an exact bit pattern match
is desired.
Suggested error message for the first condition in the example:
> Error: A direct comparison with `double.nan` is always false.
>Use `std.math.traits.isNaN` to check if the value is any NaN value.
>Use `x is double.nan` if an exact exact bit pattern match is desired.
Suggested error message for the second and sixth condition in the example:
> Error: A direct comparison with `double.init` is always false.
>Use `std.math.traits.isNaN` to check if the value is any NaN value.
>Use `x is double.init` if an exact exact bit pattern match is desired.
Suggested error message for the fourth condition in the example:
> Error: A direct comparison with `double.nan` is always false.
>Use `std.math.operations.cmp` for a total ordering that includes NaN.
This reasoning does of course not apply to an IdentityExpression (e.g. `x is
double.nan`) with `nan`, e.g. the third condition in the introductory example.
Here, we must assume the programmer knows about the issue.
The checks don’t extend to other compile-time known values that are
`double.nan`. The fifth and further conditions in the example do not produce
the error.
---
In particular, for every `EqualExpression` and `RelExpression` if the left-hand
or right-hand side ShiftExpression (or both) is a `PrimaryExpression`
designating a floating-point type’s `nan` property, that is an error; if the
left-hand or right-hand side ShiftExpression (or both) is a `PrimaryExpression`
that accesses an `init` property of or default constructs with syntactically
empty parentheses (i.e. excluding a zero-length expansion of a pack) an
optionally qualified FundamentalType that is a floating-point type, that is an
error.
The following forms of `PrimaryExpression` can result in an expression that
produces that error:
FundamentalType . Identifier
is the obvious contender when `Identifier` is `nan`. Also when it’s
Identifier
. Identifier
I don’t know if they can represent e.g. `double.nan` because `with` does not
work with built-in types:
MixinExpression
TraitsExpression
Not sure if those should count if they happen to become a compile-time nan
value. My guess is no.
( Type ) . Identifier
FundamentalType ( )
TypeCtor ( Type ) . Identifier
TypeCtor ( Type ) ( )
Those are just a little more complicated versions of obvious contender when
`Identifier` is `nan`. However, in the last case, `Type` must **syntactically**
be `FundamentalType`, and not e.g. an alias to `double`. This is so that when a
template type parameter is `double`, it won’t trigger that error.
( Expression )
If `Expression` is a `PrimaryExpression` that produces the error
[Issue 23675] Error on direct double.NaN comparison
https://issues.dlang.org/show_bug.cgi?id=23675 Dennis changed: What|Removed |Added CC||dkor...@live.nl --- Comment #1 from Dennis --- This should be a linter warning, it's not worth complicating the language for a niche error like that. --
[Issue 21821] Optimizer assumes immutables do not change, but they can in @system code
https://issues.dlang.org/show_bug.cgi?id=21821 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #12424 "fix Issue 21821 - Optimizer assumes immutables do not change, but the…" was merged into master: - ba1f1c3222a91ef6a56caa18afa3bf7464d9e422 by Walter Bright: fix Issue 21821 - Optimizer assumes immutables do not change, but they can in @system code https://github.com/dlang/dmd/pull/12424 --
[Issue 23676] New: Compilation differences w/ braceless vs brace-full static if within switch statement
https://issues.dlang.org/show_bug.cgi?id=23676 Issue ID: 23676 Summary: Compilation differences w/ braceless vs brace-full static if within switch statement Product: D Version: D2 Hardware: x86_64 OS: Mac OS X Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: brad...@chatha.dev The main, (mostly) reduced code is here: https://gist.github.com/BradleyChatha/873077996b36c9f575fa2410e03705d5 DMD version: DMD64 D Compiler v2.101.2 LDC2 version (has same issue): LDC - the LLVM D compiler (1.30.0): based on DMD v2.100.1 and LLVM 14.0.6 built with LDC - the LLVM D compiler (1.28.1) Default target: arm64-apple-darwin21.6.0 Host CPU: cyclone http://dlang.org - http://wiki.dlang.org/LDC Main issue: If you don't wrap the body of the `static if` on Line 70 inside curly braces, the compiler begins to error out with the following: ``` to_report.d(85): Error: `@safe` function `lexer.Lexer.nextVaryingLengthToken!(safePeek, Operator).nextVaryingLengthToken` cannot call `@system` function `lexer.Lexer.nextVaryingLengthToken!(safePeek, Operator).nextVaryingLengthToken.tryLexLongerOperators!(noreturn).tryLexLongerOperators` to_report.d(58):`lexer.Lexer.nextVaryingLengthToken!(safePeek, Operator).nextVaryingLengthToken.tryLexLongerOperators!(noreturn).tryLexLongerOperators` is declared here ``` It then proceeds to hang and use max out its CPU usage for a few minutes, before exiting. However, if you wrap the static if's body in braces, it will succesfully compile without the weird performance issues. Side issue: I'm very uncertain about the cause of the hang; if you delete any field within the `Token.Type` enum, the hang reduces to a couple of seconds, instead of minutes. --
[Issue 16603] [Lexical] comment definition is incorrrect
https://issues.dlang.org/show_bug.cgi?id=16603 --- Comment #2 from Kevin --- 1) The technical language specification which one would use to build a parser is still incorrect, regardless of any flavour text in the description. 2) you only addressed the second part of the issue, completely ignoring the first. 3) your "it's good enough" comment is just another reminder as to why I pivoted away from the language. --
[Issue 23677] New: log1p Documentation Doesn't Match Implementation
https://issues.dlang.org/show_bug.cgi?id=23677 Issue ID: 23677 Summary: log1p Documentation Doesn't Match Implementation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: john.michael.h...@gmail.com `std.math.exponential.log1p`'s documentation says that it is 1) more accurate for small values of x and 2) that it is a conversation of the CEPHES library. 1) It is only more accurate if a) INLINE_YL2X is true (which is likely only using the hard-ware implementation on DMD), and b) you are using either reals or it is ctfe. If neither of these are true, then the function is basically calling log(1+x), so there is no improvement in accuracy (so for floats and doubles without CTFE, it is not any different). 2) The CEPHES library has an implementation of log1p [1] using doubles that uses a Taylor expansion. The version here is not using it. The only thing it has similar is the check for a value near to 1 and special casing it and even then the special casing is different. I would recommend bringing the documentation in line with the implementation by describing the accuracy of the function more accurately and removing the references to CEPHES for this one. [1] https://github.com/jeremybarnes/cephes/blob/master/cprob/unity.c --
[Issue 23676] Compilation differences w/ braceless vs brace-full static if within switch statement
https://issues.dlang.org/show_bug.cgi?id=23676 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Severity|minor |major --- Comment #1 from RazvanN --- This is a serious issue. Bumping severity to "major" --
[Issue 23676] Compilation differences w/ braceless vs brace-full static if within switch statement
https://issues.dlang.org/show_bug.cgi?id=23676 --- Comment #2 from Bradley Chatha --- Even more strangely: If you delete any line within the body of the case statement that is guarded by the fault `static if`, compilation succeeds. What a very strange edge case this is hitting. --
[Issue 23676] Compilation differences w/ braceless vs brace-full static if within switch statement
https://issues.dlang.org/show_bug.cgi?id=23676 --- Comment #3 from Bradley Chatha --- Marking the nested function as @safe prevents the error message; allows the compilation to succeed, however the compiler does still hang for a while before it finishes. --
[Issue 23678] New: Contracts are compiled with release switch?
https://issues.dlang.org/show_bug.cgi?id=23678
Issue ID: 23678
Summary: Contracts are compiled with release switch?
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: chalu...@gmail.com
Test case:
```D
version (assert) int foo;
void test()
in (!foo)
{}
void main() {
test();
}
```
When built with `-release`, `foo` is not compiled in and compilation fails
with:
```
Error: undefined identifier `foo`
```
Should't the contract be dropped too in release builds?
--
[Issue 23679] New: 2147483647 does not exceed 0x7fffffff
https://issues.dlang.org/show_bug.cgi?id=23679
Issue ID: 23679
Summary: 2147483647 does not exceed 0x7fff
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kde...@vogtner.de
$ dmd --version
DMD64 D Compiler v2.102.0
Copyright (C) 1999-2023 by The D Language Foundation, All Rights Reserved
written by Walter Bright
$ cat sizlim.d
unittest {
ubyte [0x7fff_U] arr;
assert (true);
}
$ dmd -unittest -main -run sizlim.d
sizlim.d(2): Error: `ubyte[2147483647]` size 1 * 2147483647 exceeds 0x7fff
size limit for static array
Apart from that, shouldn't the wording and the position of the numerical limit
be "... exceeds the size limit for static arrays."
--
[Issue 23679] off-by-one error for static array size limit
https://issues.dlang.org/show_bug.cgi?id=23679 Dennis changed: What|Removed |Added CC||dkor...@live.nl Hardware|x86_64 |All Summary|2147483647 does not exceed |off-by-one error for static |0x7fff |array size limit OS|Linux |All Severity|normal |minor --
[Issue 23679] off-by-one error for static array size limit
https://issues.dlang.org/show_bug.cgi?id=23679 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #14867 "Fix 23679 - off-by-one error for static array size limit" fixing this issue: - Fix 23679 - off-by-one error for static array size limit https://github.com/dlang/dmd/pull/14867 --
[Issue 16603] [Lexical] comment definition is incorrrect
https://issues.dlang.org/show_bug.cgi?id=16603 kdevel changed: What|Removed |Added CC||kde...@vogtner.de --- Comment #3 from kdevel --- (In reply to Kevin from comment #0) > The c++ spec handles this by describing comments in a non technical manner. > See [lex.comment] in the spec. Correct: https://eel.is/c++draft/lex.comment Another technical mistake one finds in D's definition of StringLiteral: https://dlang.org/spec/lex.html#string_literals while the C++ standards carefully define what can be inside of the quotation marks (s-chars) https://eel.is/c++draft/lex.string --
[Issue 15985] [REG2.068/2.069] Code doesn't link unless compiled with -debug
https://issues.dlang.org/show_bug.cgi?id=15985 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dlang Bot --- dlang/dmd pull request #14855 "fix Issue 15985 - [REG2.068/2.069] Code doesn't link unless compiled …" was merged into master: - a476bc101e5c3172b8f18479fbf4557ba35a5a8a by Walter Bright: fix Issue 15985 - [REG2.068/2.069] Code doesn't link unless compiled with -debug https://github.com/dlang/dmd/pull/14855 --
[Issue 23545] export int a; should generate dllexport, not dllimport
https://issues.dlang.org/show_bug.cgi?id=23545 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #14680 "fix Issue 23545 - export int a; should generate dllexport, not dllimport" was merged into master: - ea945fe1843aae88ddc45c82d7218f045a752110 by Walter Bright: fix Issue 23545 - export int a; should generate dllexport, not dllimport https://github.com/dlang/dmd/pull/14680 --
[Issue 23679] off-by-one error for static array size limit
https://issues.dlang.org/show_bug.cgi?id=23679 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #14867 "Fix 23679 - off-by-one error for static array size limit" was merged into stable: - 321d4a17f231683e7d01b50661b4e8ccba8e239f by Dennis Korpel: Fix 23679 - off-by-one error for static array size limit https://github.com/dlang/dmd/pull/14867 --
