Re: How can overloads be distinguished on attributes alone?
On Monday, July 31, 2023 4:55:44 AM MDT Quirin Schroll via Digitalmars-d-learn
wrote:
> Apparently, functions can be overloaded solely distinguished by
> attributes:
> ```d
> void f(ref int x) pure { x = 1; }
> void f(ref int x) { x = 2; static int s; ++s; }
> ```
>
> I thought that, maybe, a `pure` context calls the `pure` function
> and an impure context calls the impure function, but no: Calling
> `f` leads to an ambiguity error in both contexts. Even if that
> worked, what about inferred contexts, i.e. templates? In simple
> cases, they could forward the contexts in which they are called,
> but you can instantiate a template without calling it.
>
> What am I missing here?
As things stand, the context in which a function is called is irrelevant.
All that matters is the arguments.
And actually, allowing it would complicate any functions that infer
attributes, potentially in a way that wouldn't work. For instance, if you
have a templated function that's trying to infer purity, which one should it
call? If it calls the pure one, it could be pure, but if it doesn't, it
can't be. Either way, because the context isn't yet pure or not, the context
can't be used to determine which should be called. Potentially, the compiler
could just choose the pure function in that case, but the problem gets worse
as you add more attributes.
For instance, what happens when you have a function that's pure but not
@safe and one that's @safe but not pure?
void f() pure {...}
void f() @safe {...}
Should the compiler favor calling the pure one or the @safe one? And what if
you then add something to the function that isn't @safe? If it was calling
the @safe version before, should it switch to the pure one? And if the
functions were @safe pure and @system and not pure instead
void f() @safe pure {...}
void f() @system {...}
then changing the @safety or purity of some of the other code in the
templated function could result in the loss of both attributes. And the more
attributes are involved, the more complex the situation gets.
In effect, we'd be making the attribute inference process have to go in two
directions instead of just going from the bottom up, with the added
complication that it would potentially need to choose between sets of
attributes when choosing which function overload to call.
It's not necessarily the case that we couldn't sort all of this out and come
up with a clean set of rules that allowed functions that infer their
attributes to call the correct function, but it does get pretty complicated,
and it comes with the serious downside that there's no guarantee that the
overloads even do something similar to one another. And when you consider
that it's pretty easy for a change in one part of the code to change which
attributes are inferred in another part of the code, you could easily end up
having a change in one part of your program resulting in drastically
different behavior in a seemingly unrelated part of your program. And even
worse, that change could be because of a library update, making it that much
less obvious which parts of your program could suddenly change behavior due
to a change in attributes.
And I'm probably forgetting other issues that this would add to the mix. So,
while it may very well be possible to do something along the lines of what
you're looking for, I strongly suspect that it's simply not worth it.
- Jonathan M Davis
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 16:52:03 UTC, Dennis wrote:
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote:
Is there a reason it would be difficult to make this not
compile?
No, except that might result in code breakage.
The only way you could have code breakage is if you have
```
void f() { }
extern(C) void f() { }
```
but your program never calls f. The fix would be to comment out
one of the duplicate function definitions.
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote: Is there a reason it would be difficult to make this not compile? No, except that might result in code breakage.
Re: Anyone help me with a stack dump?
On Monday, 31 July 2023 at 14:38:52 UTC, ryuukk_ wrote: Your problem lies at line 1541 You can use `ddemangle` executable to make mangled names readable, i don't know if it comes with the compiler ``` _platform_memmove pure nothrow ref @trusted wchar[] core.internal.array.appending._d_arrayappendT!(wchar[], char)._d_arrayappendT(scope return ref wchar[], scope wchar[]) void asm_parse.AsmTransformTemplate!(wchar).__unittest_L1541_C1_1() asm_parse.__unittest asm_parse.__unittest asm_parse.__unittest asm_parse.__unittest int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) runModuleUnitTests void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() _d_run_main2 _d_run_main start ``` Thank you all for your help. In the real code I have a struct (object) in the heap but in the unittests I first of all had it in place in the stack, then tried changing to the heap to see if that would fix the problem. That didn’t work. I first ran the struct initialisation routine in each one of the unittests, but I still suspect that the thing is not completely initialised. Maybe I forgot to set something in the init routine and it gets set to a sensible value in subsequent code, but all that code is not running in the unittests. An uninitialised field would be my best guess. I can see the AAarch64 instruction that it dies on and my AAarch64 is non-existent but I’ve done so much asm over the years that I can hazard a guess. It is doing something like p->field and it looks like a read instruction but I’m not sure about the operand ordering as we probably have the stupid ATT asm to deal with. Of course a write instruction is more likely to cause a crash. I could try and work out how to see all the relevant registers, could be p is a null pointer or perhaps just out of range. Really annoying as that code seems to work perfectly in normal use, and disabling that unittest block restores sanity. I really am going to have to go off and do a lot of reading.
Re: Anyone help me with a stack dump?
Your problem lies at line 1541 You can use `ddemangle` executable to make mangled names readable, i don't know if it comes with the compiler ``` _platform_memmove pure nothrow ref @trusted wchar[] core.internal.array.appending._d_arrayappendT!(wchar[], char)._d_arrayappendT(scope return ref wchar[], scope wchar[]) void asm_parse.AsmTransformTemplate!(wchar).__unittest_L1541_C1_1() asm_parse.__unittest asm_parse.__unittest asm_parse.__unittest asm_parse.__unittest int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) runModuleUnitTests void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() _d_run_main2 _d_run_main start ```
Re: Anyone help me with a stack dump?
On 7/31/23 9:09 AM, Cecil Ward wrote: The unitttests that I have just put in crash spectacularly with an access violation. I built the code with LDC for Aarch64 / OSX and I fired up lldb. I now have to learn lldb quick. (BTW Where can I get an x86 / linux build of lldb or similar ?) This is the stack dump, and I could do with some help decoding parts of it unittest_L1541 -> unittest on line 1541. Probably something in there doing appending? I myself have a hard time with lldb. I understand gdb a lot better. -Steve
Anyone help me with a stack dump?
The unitttests that I have just put in crash spectacularly with an access violation. I built the code with LDC for Aarch64 / OSX and I fired up lldb. I now have to learn lldb quick. (BTW Where can I get an x86 / linux build of lldb or similar ?) This is the stack dump, and I could do with some help decoding parts of it ⋊> cecil@janet-mac-mini ⋊> ~/a/src clear; ./got 14:01:26 0 asm_parse 0x000102a157e4 _D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbiPSQCk3sys5posix6signal9siginfo_tPvZv + 56 1 libsystem_platform.dylib0x0001a06f2a24 _sigtramp + 56 2 asm_parse 0x00010297ed88 _D4core8internal5array9appending__T15_d_arrayappendTHTAuTuZQyFNaNbNcNeMNkKQuMQxZQBa + 56 ./got: line 7: 18387 Bus error: 10 ./asm_parse ⋊> cecil@janet-mac-mini ⋊> ~/a/src sudo lldb asm_parse 14:02:49 Password: (lldb) target create "asm_parse" Current executable set to '/Users/cecil/asm_parse/src/asm_parse' (arm64). (lldb) run Process 18406 launched: '/Users/cecil/asm_parse/src/asm_parse' (arm64) Process 18406 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfff6) frame #0: 0x0001a06f2860 libsystem_platform.dylib`_platform_memmove + 544 libsystem_platform.dylib`: -> 0x1a06f2860 <+544>: ldpq0, q1, [x1, #-0x20] 0x1a06f2864 <+548>: subx1, x1, #0x20 0x1a06f2868 <+552>: subs x2, x2, #0x20 0x1a06f286c <+556>: b.hi 0x1a06f2858 ; <+536> Target 0: (asm_parse) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfff6) * frame #0: 0x0001a06f2860 libsystem_platform.dylib`_platform_memmove + 544 frame #1: 0x00016d88 asm_parse`_D4core8internal5array9appending__T15_d_arrayappendTHTAuTuZQyFNaNbNcNeMNkKQuMQxZQBa + 56 frame #2: 0x0001b1fc asm_parse`_D9asm_parse__T20AsmTransformTemplateTuZ21__unittest_L1541_C1_1FZv + 628 frame #3: 0x00010006b9b8 asm_parse`asm_parse.__unittest + 36 frame #4: 0x00010009d83c asm_parse`_D4core7runtime18runModuleUnitTestsUZ14__foreachbody6MFPS6object10ModuleInfoZi + 56 frame #5: 0x0001000ac620 asm_parse`_D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZ14__foreachbody2MFKSQCz19sections_elf_shared3DSOZi + 68 frame #6: 0x0001000acee0 asm_parse`_D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi + 56 frame #7: 0x0001000ac5b0 asm_parse`_D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZi + 32 frame #8: 0x0001000a21a4 asm_parse`_D6object10ModuleInfo7opApplyFMDFPSQBhQBdZiZi + 32 frame #9: 0x00010009d6b0 asm_parse`runModuleUnitTests + 184 frame #10: 0x0001000a6518 asm_parse`_D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv + 32 frame #11: 0x0001000a641c asm_parse`_d_run_main2 + 376 frame #12: 0x0001000a6288 asm_parse`_d_run_main + 148 frame #13: 0x0001a036bf28 dyld`start + 2236 (lldb)
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 10:55:44 UTC, Quirin Schroll wrote:
What am I missing here?
The duplicate definition check doesn't consider whether a
function is actually unambiguously callable (without e.g. traits
getOverloads), it only prevents creating the same linker symbol
multiple time. So you can even do this:
```D
void f() { }
extern(C) void f() { }
```
But this straight up looks like a bug:
```D
void g() { }
static void g() { } // static doesn't even do anything here
```
How can overloads be distinguished on attributes alone?
Apparently, functions can be overloaded solely distinguished by
attributes:
```d
void f(ref int x) pure { x = 1; }
void f(ref int x) { x = 2; static int s; ++s; }
```
I thought that, maybe, a `pure` context calls the `pure` function
and an impure context calls the impure function, but no: Calling
`f` leads to an ambiguity error in both contexts. Even if that
worked, what about inferred contexts, i.e. templates? In simple
cases, they could forward the contexts in which they are called,
but you can instantiate a template without calling it.
What am I missing here?
Re: how to make pragma(lib)'s path relative to the package's path?
On Monday, 31 July 2023 at 00:32:07 UTC, ryuukk_ wrote: I reworked the PR, here is the new link: https://github.com/dlang/dmd/pull/15479 It basically add support for ``pragma(lib, "local:bin/lib.a");`` Makes things easier, and doesn't change any old behavior Before continuing with the PR, there should be a discussion and agreement about what exact behavior is desired. That is: get input and consensus from packagers. cheers, Johan
Re: openssl 1.1 vs. 3.0 for vibe.d:tls on Ubuntu 22.04
On Friday, 28 July 2023 at 08:56:17 UTC, Guillaume Lathoud wrote: ... Now to the actual question: I am a bit confused since the source code of `vibe-d:tls` seem to support openssl-3.0, as visible e.g. in [1] but then in the config [2] I don't see anything like `"openssl-3.0"`. Maybe I missed something obvious! [1] https://github.com/vibe-d/vibe.d/blob/master/tls/vibe/stream/openssl.d#L198 [2] https://github.com/vibe-d/vibe.d/blob/master/tls/dub.sdl Could anyone please shed some light on a cleaner solution to get `vibe.d:tls` running on Ubuntu 22.04, esp. to get it running with openssl-3.0+? ... Thanks to Steven Schveighoffer for pointing this out at a better place, for reference: https://github.com/vibe-d/vibe.d/issues/2648#issuecomment-1655519155
