[Issue 24036] New: assert message in CTFE becomes `['m', 'e', 's', 's', 'a', 'g', 'e'][0..7]` if produced using std.format.format
https://issues.dlang.org/show_bug.cgi?id=24036
Issue ID: 24036
Summary: assert message in CTFE becomes `['m', 'e', 's', 's',
'a', 'g', 'e'][0..7]` if produced using
std.format.format
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: zor...@gmail.com
Manjaro/Arch x86_64, dmd 2.104.0, ldc 1.33-beta2.
If I assert(0) in CTFE with a message string produced with std.format.format,
it is output to the terminal as an `['f', 'o', 'o'][0..3]` array, and not as a
string. If I make it a string literal it works as you'd expect. cast(string)
does not seem to help. .idup makes it "foo[0..3]".
https://run.dlang.io/is/94RE0Y
---
import std;
static immutable ctfeThing = ()
{
assert(0, format("%s", "message"));
return 42;
}();
void main() {}
---
--
[Issue 24024] cannot pass class this to ref class
https://issues.dlang.org/show_bug.cgi?id=24024 Tim changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24034 --
[Issue 24035] Changing this for classes is allowed in contracts
https://issues.dlang.org/show_bug.cgi?id=24035 Tim changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24024 --
[Issue 24034] Changing this in constructor allows to modify immutable members of other instance
https://issues.dlang.org/show_bug.cgi?id=24034 Tim changed: What|Removed |Added Keywords||safe See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24024 --
[Issue 24024] cannot pass class this to ref class
https://issues.dlang.org/show_bug.cgi?id=24024 Tim changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24035 --
[Issue 24035] New: Changing this for classes is allowed in contracts
https://issues.dlang.org/show_bug.cgi?id=24035
Issue ID: 24035
Summary: Changing this for classes is allowed in contracts
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: tim.dl...@t-online.de
Pull request https://github.com/dlang/dmd/pull/15389 for issue 24024 allows to
modify `this` for classes inside functions. This is now also allowed inside
contracts, which is inconsistent with other parameters.
import std.stdio;
class C
{
void f(int i)
in
{
this = null; // OK
//i = 5; // Error: cannot modify parameter `i` in contract
}
do
{
writeln(cast(void*)this); // prints null
}
}
void main()
{
C c = new C;
c.f(1);
}
--
[Issue 24034] New: Changing this in constructor allows to modify immutable members of other instance
https://issues.dlang.org/show_bug.cgi?id=24034
Issue ID: 24034
Summary: Changing this in constructor allows to modify
immutable members of other instance
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: tim.dl...@t-online.de
Pull request https://github.com/dlang/dmd/pull/15389 for issue 24024 allows to
modify `this` for classes inside functions. In constructors this allows to
modify immutable members of another instance of the same class. The constructor
will now also return the wrong pointer.
import std.stdio;
class C
{
immutable int i;
this(int i, C other)
{
if (other !is null)
this = other;
this.i = i;
}
}
void main()
{
C c1 = new C(1, null);
writeln(c1.i); // prints 1
C c2 = new C(2, c1);
writeln(c1.i); // prints 2
writeln(c2.i); // prints 2
writeln(c1 is c2); // prints true
}
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #6 from FeepingCreature ---
The easy solution would be writing `foo!"0b?01?11"`. `q{}` is intended for
fragments of D code.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032 --- Comment #5 from Puneet Goel --- Please ignore the previous comment. There was a mistake at my end. --
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #4 from Puneet Goel ---
Even if we have to do token parsing for q{}, the following code should not
fail.
class Foo(string str) {}
void main() {
Foo!q{string str = "0X"} foo;
Foo!q{string str = "0B"} bar;
}
The compiler gives the same errors as it gives for q{0B} and q{0X}.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #3 from Puneet Goel ---
I am using q{} to write my own DSL.
For this particular thing, I need to extend binary number strings in a way
where I can write stuff like 0b?01?11 where '?' can be used for pattern
matching. So, this becomes blocking for me. Is there an easy solution, or do I
need to discover an alternate syntax for my need?
BTW, what advantage do we gain by making the compiler parse q{} as a token
string?
--
[Issue 24033] New: [compiler diagnostics] Add a way to make aliases "strong"
https://issues.dlang.org/show_bug.cgi?id=24033 Issue ID: 24033 Summary: [compiler diagnostics] Add a way to make aliases "strong" 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 This is not about language semantics, but compiler diagnostics only. Aliases are weak in the sense that error messages resolve aliases: ```d alias ints = int[]; void f(ints xs); pragma(msg, typeof()); // void function(int[] xs) ``` The only exceptions are `string`, `wstring`, and `dstring`: ```d void f(immutable(char)[] str); pragma(msg, typeof()); // void function(string str) ``` The string aliases aren’t like regular aliases: Their alias name is displayed instead of the type they alias. It might be of great pleasure to users if any alias could be marked "strong" by the programmer, so that the alias appears in diagnostics and not the aliased type. Of course, for each type, there must not be multiple different "strong" aliases. --- There are several possibilities: * re-use the `typedef` keyword: `typedef ints = int[];` * introduce an @attribute: `@strong alias ints = int[];` (applicable to `alias` only) * introduce a pragma: `pragma(strong) alias ints = int[];` (applicable to `alias` only) * introduce a trait: `__traits(strong) alias ints = int[]; (applicable to `alias` only) This is especially useful for templates with optional parameters where users are generally not interested in the defaults. --
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #2 from FeepingCreature ---
If you can replace the string with `q{0x0}`, that should work. Alternately,
pass a regular `"0x"` string.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #1 from FeepingCreature ---
Yes, Q{} is defined in the grammar as a "token string" which must consist of
valid D tokens, because it's meant to pass around fragments of source code.
"0X" stopped being a valid token in DMD 2.084.0:
https://dlang.org/changelog/2.084.0.html#deprecated_binary_literals
--
[Issue 24032] New: Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
Issue ID: 24032
Summary: Compiler is parsing string parameters to Templates
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pun...@coverify.org
Works with dmd-2.081.2.
Error with dmd-2.085 and also with current release dmd-2.104
$ dmd /tmp/test.d
/tmp/test.d(3): Error: `0X` isn't a valid integer literal, use `0X0` instead
/tmp/test.d(4): Error: `0B` isn't a valid integer literal, use `0B0` instead
// test.d
class Foo(string str) {}
void main() {
Foo!q{0X} foo;
Foo!q{0B} bar;
}
--
[Issue 23890] "Warning: cannot inline function" in core.lifetime
https://issues.dlang.org/show_bug.cgi?id=23890 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #15186 "Fix Issue 23890 - "Warning: cannot inline function" in core.lifetime" was merged into stable: - 16920c5036e18fb616cfd6fb3f74f066b16f6c2c by Vladimir Panteleev: Fix Issue 23890 - "Warning: cannot inline function" in core.lifetime https://github.com/dlang/dmd/pull/15186 --
[Issue 24024] cannot pass class this to ref class
https://issues.dlang.org/show_bug.cgi?id=24024 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dlang Bot --- dlang/dmd pull request #15389 "fix Issue 24024 - cannot pass class this to ref class" was merged into master: - 7d9679081f79e94793a13829e3adb54809e2da4e by Walter Bright: fix Issue 24024 - cannot pass class this to ref class https://github.com/dlang/dmd/pull/15389 --
