Re: Bug in DMD?
On Friday, 3 March 2023 at 01:37:42 UTC, Richard (Rikki) Andrew Cattermole wrote: On 03/03/2023 2:33 PM, ryuukk_ wrote: So it is a DMD bug? Yes and thanks to you I can now say that we can absolutely get rid of DllMain requirement for DLLs! glad the outcome is positive, and i apologies about earlier comments, i may have sounded a little bit rude
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:21:52 UTC, ryuukk_ wrote: I have some questions: 1. why does it work with LDC? 2. why does it work with DMD when build/link in 2 step? 3. why it doesn't work when DMD is invoked once for build/link I think these are probably coincidences and the answer can be summarized as "that's what ends up happening due to the details of the implementation". 4. is this a bug in DMD or my code is wrong? I would say the code is wrong in principle, though as you've noted it can still work in some specific circumstances. 5. if it's wrong, then why does it compile/no error? `extern(C) main` is a low-level feature, because it effectively turns off parts of the language. However, the rest of the program doesn't know that this is the case - currently the compiler simply assumes you know what you're doing. Maybe it's not OK that it's easy to use it by accident.
Re: Bug in DMD?
I added a note here: https://issues.dlang.org/show_bug.cgi?id=20737
Re: Bug in DMD?
On 03/03/2023 2:33 PM, ryuukk_ wrote: So it is a DMD bug? Yes and thanks to you I can now say that we can absolutely get rid of DllMain requirement for DLLs!
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:24:42 UTC, Richard (Rikki) Andrew
Cattermole wrote:
This works:
```d
extern(C) void main()
{
Stuff[5] temp = [
Stuff(),
Stuff(),
Stuff(),
Stuff(),
Stuff(),
];
stuffs = temp[];
stuffs[0].do_something();
}
```
```d
Stuff[] stuffs;
```
The problem here is dmd isn't initializing TLS with a value,
but TLS itself is working.
So it is a DMD bug?
Re: Bug in DMD?
This works:
```d
extern(C) void main()
{
Stuff[5] temp = [
Stuff(),
Stuff(),
Stuff(),
Stuff(),
Stuff(),
];
stuffs = temp[];
stuffs[0].do_something();
}
```
```d
Stuff[] stuffs;
```
The problem here is dmd isn't initializing TLS with a value, but TLS
itself is working.
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:11:06 UTC, Vladimir Panteleev wrote:
On Friday, 3 March 2023 at 01:07:07 UTC, ryuukk_ wrote:
I couldn't figure out dustmite, so i started from 0 and
managed to hit something:
https://github.com/ryuukk/dmd_bug
``Assertion failed: array index out of bounds, file
game\app.d, line 5``
Wich indicates probably TLS problem?
Yeah... `rt.a.stuffs` is a TLS variable. The D runtime manages
TLS. `extern(C) main` bypasses D runtime initialization.
I have some questions:
1. why does it work with LDC?
2. why does it work with DMD when build/link in 2 step?
3. why it doesn't work when DMD is invoked once for build/link
4. is this a bug in DMD or my code is wrong?
5. if it's wrong, then why does it compile/no error?
```sh
#!/usr/bin/env bash
set -e
build_dmd() {
echo "build dmd"
dmd \
-debug -g \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
stuff/rt/object.d \
game/app.d \
-of=game.exe
}
build_ldc() {
echo "build ldc"
ldc2 \
-d-debug -g \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
stuff/rt/object.d \
game/app.d \
-of=game.exe
}
build_dmd_and_link() {
echo "build dmd and link (2step)"
dmd \
-debug -g -c \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
stuff/rt/object.d \
game/app.d \
-of=game.obj
dmd \
-debug -g \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
game.obj \
-of=game.exe
}
build_ldc
./game.exe
rm game.obj game.exe
build_dmd_and_link
./game.exe
rm game.obj game.exe
build_dmd
./game.exe
rm game.obj game.exe
```
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:07:07 UTC, ryuukk_ wrote: I couldn't figure out dustmite, so i started from 0 and managed to hit something: https://github.com/ryuukk/dmd_bug ``Assertion failed: array index out of bounds, file game\app.d, line 5`` Wich indicates probably TLS problem? Yeah... `rt.a.stuffs` is a TLS variable. The D runtime manages TLS. `extern(C) main` bypasses D runtime initialization.
Re: Bug in DMD?
I couldn't figure out dustmite, so i started from 0 and managed to hit something: https://github.com/ryuukk/dmd_bug ``Assertion failed: array index out of bounds, file game\app.d, line 5`` Wich indicates probably TLS problem? This now reminds me of: https://issues.dlang.org/show_bug.cgi?id=23310 I am clueless what to do next, but at least now there is a small repro available for knowledgeable people
Re: Bug in DMD?
On 03/03/2023 10:38 AM, ryuukk_ wrote: On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew Cattermole wrote: There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with. I have no idea what does 1. mean, as for 2. do you have a link for a guide how to setup "dustmite"? When debugging, native debuggers i.e. Visual Studio, will provide you with the disassembly of the function currently being executed. Between this and other entries in the call stack, you can generally figure out what the statement is being executed just by looking at things like call instructions. The symbols there will be accurate.
Re: Bug in DMD?
On 3/2/23 15:34, ryuukk_ wrote: > the problem is not that it can run in the background, the problem is > figuring out > > 1. how to install > 2. how to setup > 3. how to run I haven't used it myself but dustmite seems to be integrated into dub. 'dub dustmite <...>' Ali
Re: Bug in DMD?
On 03/03/2023 12:34 PM, ryuukk_ wrote: 1. how to install Already is. Comes with dmd and ldc. You can also just do ``$ dub run digger -- args``. 2. how to setup > 3. how to run It is a bit of a pain but the basics is you need some sort of compilation command, list of sources and a test to confirm if it still fails. https://github.com/CyberShadow/DustMite/wiki#how-to-use-it
Re: Bug in DMD?
On Thursday, 2 March 2023 at 22:24:11 UTC, H. S. Teoh wrote: On Thu, Mar 02, 2023 at 09:55:55PM +, ryuukk_ via Digitalmars-d-learn wrote: On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote: > On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) > Andrew > Cattermole wrote: [...] > > 2. Dustmite, so we have something we can work with. > > [...] 2. do you have a link for a guide how to setup > "dustmite"? https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Dustmite automatically reduces your code to a minimal example that still exhibits the same problem, good for bug reports that are easily reproducible. Also useful if you don't want to publicly share the code for whatever reason, but still want to provide enough information so that the dmd devs can find the problem and fix it. [...] That's is not something i like doing, it should just work, i shouldn't have to debug DMD, that aint my job Dustmite can run in the background on a temporary copy of your code, you don't have to babysit it and can work on other things while it's doing its thing. T the problem is not that it can run in the background, the problem is figuring out 1. how to install 2. how to setup 3. how to run i was initially working on my game, i shouldn't have to take a 1 week break to debug dmd
Re: Bug in DMD?
On Thu, Mar 02, 2023 at 09:55:55PM +, ryuukk_ via Digitalmars-d-learn wrote: > On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote: > > On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew > > Cattermole wrote: [...] > > > 2. Dustmite, so we have something we can work with. > > > > [...] 2. do you have a link for a guide how to setup "dustmite"? https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Dustmite automatically reduces your code to a minimal example that still exhibits the same problem, good for bug reports that are easily reproducible. Also useful if you don't want to publicly share the code for whatever reason, but still want to provide enough information so that the dmd devs can find the problem and fix it. [...] > That's is not something i like doing, it should just work, i shouldn't > have to debug DMD, that aint my job Dustmite can run in the background on a temporary copy of your code, you don't have to babysit it and can work on other things while it's doing its thing. T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Re: Bug in DMD?
On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote: On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew Cattermole wrote: There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with. I have no idea what does 1. mean, as for 2. do you have a link for a guide how to setup "dustmite"? Better, can i send you a zip of my project? i'm not sure i'm willing to waste any more time trying to figure out what is wrong That's is not something i like doing, it should just work, i shouldn't have to debug DMD, that aint my job
Re: Bug in DMD?
On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew Cattermole wrote: There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with. I have no idea what does 1. mean, as for 2. do you have a link for a guide how to setup "dustmite"?
Re: Bug in DMD?
There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with.
Re: Bug in DMD?
It crashes with a weird message, address doesn't match the mangled name: ``C:\dev\kdom\projects\dawn\gl\glad\loader.d`` inside: ``module dawn.gl.glad.loader;`` 
Bug in DMD?
Hello, I encountered a weird issue, my program segfault when i feed DMD with my files and static libs It doesn't when i compile with LDC If i split the compile/link in 2 different steps, then all works correctly DMD (1step: ⛔): https://gist.github.com/ryuukk/f0ae2ae0c8980219c04d0c6d8678940d LDC (1step: ✅): https://gist.github.com/ryuukk/4c7706697583431389d5e2074548f7c4 DMD (2step: ✅): https://gist.github.com/ryuukk/a0373339e590ecdae91e3f05b2d81bf4 Looks like DMD is messing things up when mixing code with static libraries? Toolchains: - DMD32 D Compiler v2.102.1 - LDC - the LLVM D compiler (1.32.0-beta1):
Re: Bug in dmd?
On Wednesday, 15 June 2022 at 16:53:13 UTC, mw wrote: Create a simple test case, file bug at: https://issues.dlang.org/ I tried. No luck.
Re: Bug in dmd?
Create a simple test case, file bug at: https://issues.dlang.org/
Re: Bug in dmd?
On Wednesday, 15 June 2022 at 09:24:35 UTC, Dukc wrote: Now when I think of it, perhaps the fact that private `printHelp` has the same name as the public `printHelp` is somehow confusing dmd. If you try to rename the private `printHelp` and it's call in the public one to something else, you might get some insight on what triggers this behaviour. I tried `private void printHelp` -> `package void printHelp1`. It didn't help.
Re: Bug in dmd?
On Wednesday, 15 June 2022 at 09:21:28 UTC, user1234 wrote: On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote: I have [pretty simple code in my library](https://github.com/andrey- [Line (2) produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=true#step:5:12) `undefined reference to '_D3std7sumtype__T7SumTypeTS8argparse4help2AATSQtQm2BBZQBl6__dtorMFNaNbNiNfZv'` (it demangles to `pure nothrow @nogc @safe void std.sumtype.SumType!(argparse.help.AA, argparse.help.BB).SumType.__dtor()`) If I comment line (2) then everything is good (no link errors). Note that there is the same code at (1) which doesn't produce any error. Any idea what's going on? That can be a template instance that's emitted somewhere else, i.e the thing is there but the mangle is different. maybe try to find if the dtor is there with `mn -S` on each object. Another thing to try in these situations is to see if that works with `-allinst`. I tried to call dmd the same way as dub does with `-allinst` added to all calls. Got the same linker issue. `nm` shows that `app.d` refers to dtor which is not defined in `.a`: ```bash $ nm .../liball_argparse.a|egrep 'argparse.+dtor' $ nm .../all_getting_started-basic.o|egrep 'argparse.+dtor' U _D3std7sumtype__T7SumTypeTS8argparse4help2AATSQtQm2BBZQBl6__dtorMFNaNbNiNfZv ```
Re: Bug in dmd?
On Wednesday, 15 June 2022 at 07:38:36 UTC, JG wrote: I tried to reproduce it but wasn't able (I guess it is some interplay with the rest of your code): I tried this first but got the same result as you. I think my small library overheats DMD's template engine.
Re: Bug in dmd?
On Tuesday, 14 June 2022 at 23:56:58 UTC, Andrey Zherikov wrote: On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote: No idea. The functions seems indeed to be exactly the same, so I assume this is a DMD bug. It cannot be a bug in `std.sumtype`, since that would trigger in both of the templates. This definitely triggers some bug in DMD because this `private void printHelp ...` function is not really `private` as it's called from [another module](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/internal.d#L786) and DMD doesn't catch this. Now when I think of it, perhaps the fact that private `printHelp` has the same name as the public `printHelp` is somehow confusing dmd. If you try to rename the private `printHelp` and it's call in the public one to something else, you might get some insight on what triggers this behaviour.
Re: Bug in dmd?
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote: I have [pretty simple code in my library](https://github.com/andrey- [Line (2) produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=true#step:5:12) `undefined reference to '_D3std7sumtype__T7SumTypeTS8argparse4help2AATSQtQm2BBZQBl6__dtorMFNaNbNiNfZv'` (it demangles to `pure nothrow @nogc @safe void std.sumtype.SumType!(argparse.help.AA, argparse.help.BB).SumType.__dtor()`) If I comment line (2) then everything is good (no link errors). Note that there is the same code at (1) which doesn't produce any error. Any idea what's going on? That can be a template instance that's emitted somewhere else, i.e the thing is there but the mangle is different. maybe try to find if the dtor is there with `mn -S` on each object. Another thing to try in these situations is to see if that works with `-allinst`.
Re: Bug in dmd?
On Tuesday, 14 June 2022 at 23:56:58 UTC, Andrey Zherikov wrote:
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both of the
templates.
This definitely triggers some bug in DMD because this `private
void printHelp ...` function is not really `private` as it's
called from [another
module](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/internal.d#L786) and DMD doesn't catch this.
I tried to reproduce it but wasn't able (I guess it is some
interplay with the rest of your code):
```d
import std.sumtype;
alias CC = SumType!(AA,BB);
struct AA {}
struct BB
{
CC[] c;
}
private void ppp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config config)
{
auto cc = CC(AA()); // (1)
}
private void printHelp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config config)
{
auto cc = CC(AA()); // (2)
}
void printHelp(T, Output)(auto ref Output output, in Config
config)
{
ppp(output, CommandArguments!T(config), config);
printHelp(output, CommandArguments!T(config), config);
}
struct CommandArguments(T) {
T x;
}
struct Config {}
void main() {
string test;
Config config;
CommandArguments!int commandArguments;
printHelp!(int,string)(test,commandArguments,config);
}
```
Re: Bug in dmd?
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote: No idea. The functions seems indeed to be exactly the same, so I assume this is a DMD bug. It cannot be a bug in `std.sumtype`, since that would trigger in both of the templates. This definitely triggers some bug in DMD because this `private void printHelp ...` function is not really `private` as it's called from [another module](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/internal.d#L786) and DMD doesn't catch this.
Re: Bug in dmd?
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/help.d#L27-L47):
```d
alias CC = SumType!(AA,BB);
struct AA {}
struct BB
{
CC[] c;
}
private void ppp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config config)
{
auto cc = CC(AA()); // (1)
}
private void printHelp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config config)
{
auto cc = CC(AA()); // (2)
}
void printHelp(T, Output)(auto ref Output output, in Config
config)
{
ppp(output, CommandArguments!T(config), config);
printHelp(output, CommandArguments!T(config), config);
}
```
[Line (2)
produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=true#step:5:12) `undefined reference to '_D3std7sumtype__T7SumTypeTS8argparse4help2AATSQtQm2BBZQBl6__dtorMFNaNbNiNfZv'` (it demangles to `pure nothrow @nogc @safe void std.sumtype.SumType!(argparse.help.AA, argparse.help.BB).SumType.__dtor()`)
If I comment line (2) then everything is good (no link errors).
Note that there is the same code at (1) which doesn't produce
any error. Any idea what's going on?
No idea. The functions seems indeed to be exactly the same, so I
assume this is a DMD bug. It cannot be a bug in `std.sumtype`,
since that would trigger in both of the templates.
BTW, thanks for taking the effort to write your question this
well (demagling, link to your library and all).
Bug in dmd?
I have [pretty simple code in my
library](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/help.d#L27-L47):
```d
alias CC = SumType!(AA,BB);
struct AA {}
struct BB
{
CC[] c;
}
private void ppp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config config)
{
auto cc = CC(AA()); // (1)
}
private void printHelp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config config)
{
auto cc = CC(AA()); // (2)
}
void printHelp(T, Output)(auto ref Output output, in Config
config)
{
ppp(output, CommandArguments!T(config), config);
printHelp(output, CommandArguments!T(config), config);
}
```
[Line (2)
produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=true#step:5:12) `undefined reference to '_D3std7sumtype__T7SumTypeTS8argparse4help2AATSQtQm2BBZQBl6__dtorMFNaNbNiNfZv'` (it demangles to `pure nothrow @nogc @safe void std.sumtype.SumType!(argparse.help.AA, argparse.help.BB).SumType.__dtor()`)
If I comment line (2) then everything is good (no link errors).
Note that there is the same code at (1) which doesn't produce any
error. Any idea what's going on?
Re: Is this a bug in dmd 2.067 for struct initializers?
On Sunday, February 22, 2015 17:45:48 Ali Çehreli via Digitalmars-d-learn wrote: > On 02/22/2015 03:17 PM, Martin Nowak wrote: > > On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: > >> I've gone with "static this()" approach and it works. > > > > You should use shared static this to initialize immutable variables. > > Is that because they are not thread-local? If so, initializing the same > variable in multiple 'static this()' blocks would indeed be a race > condition. Very important... Yeah. It really should be illegal to initialize immutable variables in non-shared static constructors. https://issues.dlang.org/show_bug.cgi?id=4923 - Jonathan M Davis
Re: Is this a bug in dmd 2.067 for struct initializers?
On Monday, 23 February 2015 at 04:04:08 UTC, ketmar wrote: On Mon, 23 Feb 2015 02:15:08 +, stewarth wrote: On Monday, 23 February 2015 at 02:10:09 UTC, amber wrote: On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote: On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with "static this()" approach and it works. You should use shared static this to initialize immutable variables. OK, thanks a lot for the help. Cheers, Stew Oops, replied under my friends account ... sorry for the confusion. I am assuming this is only if I have more than one thread? do not count on that. even if *you* never create additional threads, any library can. it's better to always remember that you don't control all execution pathes then be sorry later. Ah yes of course. Good point and thanks for the help. Stew
Re: Is this a bug in dmd 2.067 for struct initializers?
On Mon, 23 Feb 2015 02:15:08 +, stewarth wrote: > On Monday, 23 February 2015 at 02:10:09 UTC, amber wrote: >> On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote: >>> On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with "static this()" approach and it works. >>> >>> You should use shared static this to initialize immutable variables. >> >> OK, thanks a lot for the help. >> >> Cheers, >> Stew > > Oops, replied under my friends account ... sorry for the confusion. > > I am assuming this is only if I have more than one thread? do not count on that. even if *you* never create additional threads, any library can. it's better to always remember that you don't control all execution pathes then be sorry later. signature.asc Description: PGP signature
Re: Is this a bug in dmd 2.067 for struct initializers?
On Monday, 23 February 2015 at 02:10:09 UTC, amber wrote: On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote: On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with "static this()" approach and it works. You should use shared static this to initialize immutable variables. OK, thanks a lot for the help. Cheers, Stew Oops, replied under my friends account ... sorry for the confusion. I am assuming this is only if I have more than one thread? Thanks, Stew
Re: Is this a bug in dmd 2.067 for struct initializers?
On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote: On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with "static this()" approach and it works. You should use shared static this to initialize immutable variables. OK, thanks a lot for the help. Cheers, Stew
Re: Is this a bug in dmd 2.067 for struct initializers?
On 02/22/2015 03:17 PM, Martin Nowak wrote: On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with "static this()" approach and it works. You should use shared static this to initialize immutable variables. Is that because they are not thread-local? If so, initializing the same variable in multiple 'static this()' blocks would indeed be a race condition. Very important... Ali
Re: Is this a bug in dmd 2.067 for struct initializers?
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with "static this()" approach and it works. You should use shared static this to initialize immutable variables.
Re: Is this a bug in dmd 2.067 for struct initializers?
On Thursday, 19 February 2015 at 07:46:51 UTC, Ali Çehreli wrote:
On 02/18/2015 10:39 PM, stewarth wrote:
> This works under dmd 2066.1 but fails under dmd 2.067-b2.
I don't know whether it is a bug.
> struct B {
> A* a;
In any case, that must be immutable(A)*.
> }
>
> static immutable B[] someB = [{a:&someA[0]}, {a:&someA[1]}];
> I want it to initialize at runtime before main(). I don't
> actually want any CTFE stuff here.
Then you need 'static this()' (or 'shared static this()'):
static immutable B[] someB;
static this() {
someB = [ B(&someA[0]), B(&someA[1]) ];
}
Note that I could not use the named member syntax because in my
case the compiler cannot know what the right-hand side
expression is. However, it is still possible with a temporary
where the type is explicit as in your case:
static this() {
immutable B[] tmp = [ {a:&someA[0]}, {a:&someA[1]} ];
someB = tmp;
}
Ali
Hi Ali,
Thanks for the help.
I've gone with "static this()" approach and it works. In a way
it's cleaner because it's explicit that these variables are only
initialised at runtime before d_main(). At least that's how I
understand things :)
It would be nice if the named syntax also worked in static
this(), maybe I'll file an ER for it. I'm a big fan of the whole
named args thing in Python, which from a quick search has been
discussed before in the forums.
Cheers,
Stew
Re: Is this a bug in dmd 2.067 for struct initializers?
On 02/18/2015 10:39 PM, stewarth wrote:
> This works under dmd 2066.1 but fails under dmd 2.067-b2.
I don't know whether it is a bug.
> struct B {
> A* a;
In any case, that must be immutable(A)*.
> }
>
> static immutable B[] someB = [{a:&someA[0]}, {a:&someA[1]}];
> I want it to initialize at runtime before main(). I don't
> actually want any CTFE stuff here.
Then you need 'static this()' (or 'shared static this()'):
static immutable B[] someB;
static this() {
someB = [ B(&someA[0]), B(&someA[1]) ];
}
Note that I could not use the named member syntax because in my case the
compiler cannot know what the right-hand side expression is. However, it
is still possible with a temporary where the type is explicit as in your
case:
static this() {
immutable B[] tmp = [ {a:&someA[0]}, {a:&someA[1]} ];
someB = tmp;
}
Ali
Is this a bug in dmd 2.067 for struct initializers?
Hi All,
This works under dmd 2066.1 but fails under dmd 2.067-b2.
---
struct A {
int val;
}
static immutable A[] someA = [{val:1}, {val:2}];
struct B {
A* a;
}
static immutable B[] someB = [{a:&someA[0]}, {a:&someA[1]}];
void main()
{
writefln("a:%s", someA);
writefln("b:%s", someB);
}
---
Error under DMD 2.067-b2:
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '&[A(1), A(2)][0]'
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '&[A(1), A(2)][1]'
Is this a bug, or a deliberate change?
I'm thinking a bug because I want it to initialize at runtime
before main(). I don't actually want any CTFE stuff here.
Thanks,
stew
