kelbon
Possible problems with __PRETTY_FUNCTION__-based type descriptors
I've hit an issue where an any_cast is failing unexpectedly, specifically in a Clang build targetting WASM. The same program executes as expected when built for native using the exact same version of Clang, for both Windows and Linux. I can't be 100% sure I don't have some UB somewhere, but I investigated the anyany code a bit and found the ANYANY_ASSUME_NO_DLLS logic, and when I defined this, the WASM build worked. Note that all these tests are in a simple program with no dlls.
I don't really have any clear idea of what is wrong I'm afraid - I did a bit of testing and as far as I can see, the Clang __PRETTY_FUNCTION__ output matches regardless of the target being native or WASM. If you have some ideas for what to test further, I can do so.
In my tests though, I also hit some strange-looking behaviour with __PRETTY_FUNCTION__ on GCC, so I wonder if its guarantees are sufficient for this to be used as the default way of discriminating.
Its interesting, can you provide minimal example with different behavior for WASM / other targets?
I'll have another go at reproducing it tomorrow. So far though I've only seen the issue as it manifests in my full program, so it may be tough.
Also your godbolt link looks like gcc bug
Maybe so. I've not made use of __PRETTY_FUNCTION__ myself, and couldn't find much information on what guarantees there are, if any.
So I'm pretty sure at this point that I've hit a codegen bug with WASM, and it's a nightmare to reduce so I'm gonna have to shelve for now. I have no idea if it's actually related to the pretty function issue, but it could be so there's not really any point pursuing that until the codegen issue is resolved one way or another.
FWIW though, regardless of WASM, from what I've heard recently I feel like relying on pretty function for correctness is pretty risky. A GCC maintainer confirmed the above is essentially a bug, but also hinted it may not be likely to get addressed anytime soon. Furthermore, someone else pointed out another inconsistency, and this one occurs on both GCC and Clang...
So I'm pretty sure at this point that I've hit a codegen bug with WASM, and it's a nightmare to reduce so I'm gonna have to shelve for now. I have no idea if it's actually related to the pretty function issue, but it could be so there's not really any point pursuing that until the codegen issue is resolved one way or another.
FWIW though, regardless of WASM, from what I've heard recently I feel like relying on pretty function for correctness is pretty risky. A GCC maintainer confirmed the above is essentially a bug, but also hinted it may not be likely to get addressed anytime soon. Furthermore, someone else pointed out another inconsistency, and this one occurs on both GCC and Clang...
Perhaps a good solution would be C++26 reflection, if it allows creating a unique ID for each type. For now, i can only suggest ANYANY_ASSUME_NO_DLLS =(
Yeah I'd imagine that would probably be possible, probably scope to make an efficient binary form of id too. Would be an interesting use case.
Anyway yeah, for now I'm going with ANYANY_ASSUME_NO_DLLS. I'll find a way to deal with my DLL-based project usage when I need to ;)