On Sunday, 14 June 2020 at 10:35:51 UTC, Stefan Koch wrote:
> On Sunday, 14 June 2020 at 10:24:33 UTC, Walter Bright wrote:
>> On 6/14/2020 2:52 AM, Mathias LANG wrote:
>>> https://github.com/dlang/dmd/pull/7099
>>> It's essentially putting rdmd in the compiler because rdmd was considered too slow.
>>
>> Thank you. I see I was involved in the discussion.
>>
>> The issue is then should the implementer of the module decide if it is header-only (i.e. pragma(root)) or the caller (-i).
>>
>> It would probably be better as the implementer, as a header-only library has to be designed for it. It also means the user needn't need to set the switches, he can just compile.
>
> I agree with everything except for the name.

I take it back.
I thought this was per_symbol rather than per_module.

I would be on-board with doing this per symbol.
And infact I am implementing it right now.
To see where the challenges are.

On Sunday, 14 June 2020 at 09:42:45 UTC, Walter Bright wrote:
> I don't know what -i does exactly, or why it was added.

-i is the most exciting thing that happened in the compiler from like 2015 up to 2018. Enormously useful in efficient, seamless builds, serious gamechanger in using D.

Don't touch it!

On Sunday, 14 June 2020 at 10:24:33 UTC, Walter Bright wrote:
> It would probably be better as the implementer, as a header-only library has to be designed for it.

That's not true. -i just works with almost any D code. It is enormously useful exactly the way it is.

On 6/14/20 11:36 AM, Adam D. Ruppe wrote:
> On Sunday, 14 June 2020 at 10:24:33 UTC, Walter Bright wrote:
>> It would probably be better as the implementer, as a header-only library has to be designed for it.
> 
> That's not true. -i just works with almost any D code. It is enormously useful exactly the way it is.

What code wouldn't it work with? Would be good to document those. "How to write a header-only D library". Blog post!

On Sunday, 14 June 2020 at 15:31:05 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 June 2020 at 09:42:45 UTC, Walter Bright wrote:
>> I don't know what -i does exactly, or why it was added.
>
> -i is the most exciting thing that happened in the compiler from like 2015 up to 2018. Enormously useful in efficient, seamless builds, serious gamechanger in using D.
>
> Don't touch it!

I fully agree, but there's a very sad side-story to it:

https://github.com/dlang/tools/pull/271
https://github.com/dlang/tools/pull/290

tl;dr: rund [1] (a modern variant of rdmd without the compile twice bug + useful features like including flags inside the file header) was a result of this revert debacle. At this point rund is vastly superior to rdmd and there's almost zero talk about it (both: the rdmd debacle + rund).

[1] https://github.com/dragon-lang/rund

Am Sun, 14 Jun 2020 01:36:50 -0700 schrieb Walter Bright:


> and the pragma(root) will cause the compiler to behave as if you'd
> typed:
> 
>    dmd atom electron

If it really does only that, it'll lead to duplicate symbol errors as soon as electron introces any symbols which do not have weak linkage. This includes global variables, but that may be expected not to work in header-only libraries.

This problem however also occurs because of initZ, TypeInfo and other special symbol generated for structs and classes. As mentioned in the other post, even if you don't declare structs or classes, right now this does not work because of duplicate ModuleInfo.


But those are implementation issues.


Regarding the feature: I don't really like the name "root". I also wonder whether it would not be better to unify all "emit to object file" use cases into one pragma:

// CTFE only function (no codegen)
pragma(emit, never)
void foo() {}

// can be used at runtime (codegen) but never output a symbol
pragma(emit, inliner)

// Only once, in the defining module / CU
pragma(emit, normal)

// Once into each into CUs importing this. Not into defining CU
pragma(emit, imports)

// Emit into all importing and defining CU
pragma(emit, all)



It should be noted that due to D's name mangling, whenever symbols are emitted multiple times (imports, all) they have to be weak and will be merged by linker, so you never get multiple copies.

If a static inline effect is desired (emit multiple copies with independent addresses), we'd need pragma(emit, all_copy) and pragma(import_copy). However, I'm not sure if this should be part of pragma(emit), or an additional orthogonal pragma.
-- 
Johannes

On Sunday, 14 June 2020 at 16:42:36 UTC, Johannes Pfau wrote:
> Am Sun, 14 Jun 2020 01:36:50 -0700 schrieb Walter Bright:
>
>
>>    [...]
>
> If it really does only that, it'll lead to duplicate symbol errors as soon as electron introces any symbols which do not have weak linkage. This includes global variables, but that may be expected not to work in header-only libraries.
>
> [...]

Proof of concept here: https://github.com/dlang/dmd/pull/11272

On 6/14/2020 8:36 AM, Adam D. Ruppe wrote:
> On Sunday, 14 June 2020 at 10:24:33 UTC, Walter Bright wrote:
>> It would probably be better as the implementer, as a header-only library has to be designed for it.
> 
> That's not true. -i just works with almost any D code. It is enormously useful exactly the way it is.

If you're building a project using separate compilation, I doubt you'd want an import with large functions in it being compiled over and over into multiple object files. Also, you probably don't want dependencies leaking into the imported code.

On Monday, 15 June 2020 at 00:17:42 UTC, Walter Bright wrote:
> If you're building a project using separate compilation, I doubt you'd want an import with large functions in it being compiled over and over into multiple object files.

If you're using separate compilation, you won't pass -i.

You might pass -i=-foo.bar though; the optional pattern part of the argument is pretty flexible to pick and choose what you do and do not want.

On Sunday, 14 June 2020 at 16:19:54 UTC, Seb wrote:
> I fully agree, but there's a very sad side-story to it:

Indeed, rund is a practical piece of work that actually adds value over dmd -i for some cases.

Why was that rdmd change reverted? Is it just because the other compiler versions in repos didn't support -i?