Potential of a compiler that creates the executable at once

[Dave P.]

On Thursday, 10 February 2022 at 22:11:13 UTC, max haughton wrote:
> On Thursday, 10 February 2022 at 22:06:30 UTC, Dave P. wrote:
>> On Thursday, 10 February 2022 at 09:41:12 UTC, rempas wrote:
>>> [...]
>>
>> I think it would be interesting to combine a compiler and a 
>> linker into a single executable. Not necessarily for speed 
>> reasons, but for better diagnostics and the possibility of 
>> type checking external symbols. Linker errors can sometimes be 
>> hard to understand in the presence of inlining and 
>> optimizations. The linker will report references to symbols 
>> not present in your code or present in completely different 
>> places.
>>
>> [...]
>
> This goes away if you do a debug build, which most (all 
> professionals I'm aware of) people do.
>

That *is* a debug build:

```sh
ldc2 example.d -O0

Undefined symbols for architecture arm64:
   "__D7example9some_funcFiZi", referenced from:
       __D7example3fooFiZi in example.o
       __D7example3barFiZi in example.o
       __D7example3bazFiZi in example.o
       __D7example3quxFiZi in example.o
       __Dmain in example.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)
Error: /usr/bin/cc failed with status: 1
```

I’m used to it at this point, but for people new to the C-style 
model of separate compilation it is extremely confusing. It’s 
made worse by the name mangling required to get C-linkers to link 
code from more modern languages.

>
> And why should the compiler do something the linker is going to 
> do anyway? It would have to wait until after linking anyway 
> because you might want a symbol to be defined somewhere else.
>

You would still give the compiler libraries if you wanted them 
defined elsewhere and in my idea the compiler would also be the 
linker so there is no “the linker is going to do anyway”.