On 6/12/20 8:52 PM, Manu wrote:
> On Fri, Jun 12, 2020 at 11:25 PM Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
> On 6/8/20 2:14 AM, Manu wrote:
> > In C/C++, inline says that a function will be emit to the binary
> only
> > when it is called, and the function is marked with internal
> linkage (it
> > is not visible to the linker from the symbol table)
>
> By my recollection this is not the case for C++, at all.
>
> * "inline" does NOT change a function's linkage in C++. You may have
> inline functions with internal linkage (static inline) or (default)
> external linkage. This is important because e.g. defining a static
> variable in an extern inline function will have the same address in all
> calls to the function.
>
>
> It absolutely changes the linkage.
No.
Dump a binary with and without `inline`; look at the link flags... they are different.
> I believe it uses what LLVM calls 'ChooseOne' in its code generator, I
> don't know about 'standard' linker terminology, if such a thing exists.
It does: http://eel.is/c++draft/basic.link
> It's clearly in the spec too:
> """
>
> 1. There may be more than one definition
> <https://en.cppreference.com/w/cpp/language/definition#One_Definition_Rule> of
> an inline function or variable in the program as long as each
> definition *appears in a different translation unit* and (for
> non-static inline functions and variables) all definitions are
> identical. For example, an inline function or an inline variable may
> be defined in a header file that is #include'd in multiple source files.
>
> """
The quote does not even contain the word "linkage".
I'm insisting on this because it happens so often. We need to use the
terms with the same meaning, otherwise we get bogged down in silly side
quests "it doesn't change linkage" - "oh but it does" and there is no
progress.
That's because this is a C++ spec, and C++ is not a linker. The spec just specifies the required semantics, and the compiler implements them.
The compiler happens to implement them appropriately for the linking ecosystem (by using appropriate link flags), because that's how native code works... you build modules and then link them with a linker which is outside the domain of the language spec.
The whole point is that different languages can interact with each other successfully in 'linker space'. Unless we want to have a self-contained language island, we can't ignore that a linker will link our code (together with other code), and the compilers output has to work properly in that environment.
Like C++, we don't need to spec details about link flags, but the compiler implementation still needs to implement them in those terms, cus that's how the ecosystem has been designed to work.
I imagine any changes made here would have a similar expression in the D spec as what you read in the C++ spec... and the practical reality is the implementation will apply the appropriate link flags to the symbols.