https://issues.dlang.org/show_bug.cgi?id=19570
Manu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal --- Comment #3 from Manu <[email protected]> --- I'm not sure why it's critical, I don't recall doing that... Perhaps it was an accident. I created another bug critical yesterday, but that was bad codegen, failing to do the ABI proper. > Besides, the reason it is emitted to the object file is in the case someone > in another module takes the address of it. >From another module being emit to the same object file, or another module compiled into a separate object file? I would expect taking the address would cause the code to be emit locally to the module that's taking the address, rather than externing to a copy in the module it's declared. > Also, the linker is supposed to elide unreferenced COMDATs, so it should go > away. It doesn't. That's motivating this issue. But also I'm upset that it was there in the first place. That's distinctly *not* honouring my "inline" request. > This needs a better rationale for why it is a bug, let alone critical. I mean, I don't feel like I should be presenting an argument here... an explicit inline feature that doesn't do what's written on the tin seems like a bug. I think the rationale needs to support why it wouldn't behave the way you'd expect. Suggesting that we have to emit the function because a 3rd party should be able to link to it is weird, because that's totally self-defeating. Why is it inline then? I expect that if I've explicitly marked it inline, then I can not extern to it, that would be the whole point. Code that calls an inline function should either inline it as preferred, or if it decides not to for some reason, emit the code locally into the referencing module (and perhaps even don't emit a symbol name for the not-inline code). --
