First Draft: Symbol Representation (Export)

[Richard (Rikki) Andrew Cattermole]

On 30/03/2024 2:33 AM, Johan wrote:
> On Thursday, 29 February 2024 at 11:15:07 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> D's support for shared libraries has historically presented challenges 
>> for users, especially when dealing with complex use cases. This 
>> proposal aims to improve the user experience by establishing a user 
>> story that will provide a consistent and user-friendly approach to 
>> usage and compilation of binaries without a thorough understanding of 
>> linkers.
>>
>> With the recent resolution of dmd's exportation support on Windows 
>> (druntime support is still under development), we are now ready to 
>> focus on making D's shared library capabilities more accessible and 
>> usable for common use cases.
>>
>> Links: 
>> [current](https://gist.githubusercontent.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e/11e36e8a332324c5323792da2835337d0306a6c9) [latest](https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e)
> 
> "The compiler must not inline a function from an out of binary module if 
> it refers to non-exported symbols."
> 
> I think this should instead be detected at module compile time, giving a 
> warning that an exported pragma(inline, true) function is calling a 
> hidden function.
> Let's keep `pragma(inline, true)` as a very strong inlining hint.
> 
> -Johan

That statement isn't just for pragma inline, it also applies to 
preventing the backend from performing an inline too.

However in saying that currently I have enough reasons to believe that 
honoring it will only result in linker errors that to users is just a 
garbled mess. Even with the warning from the compiler.

I would need evidence that an inlined symbol accessing another binaries 
symbol that was not exported will work. Right now I have no evidence 
that this is possible. Therefore this change would allow non-linking 
code that had a zero percent chance to link, to pass compilation.