GSOC Linker project

[Steven Schveighoffer]

On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley  
<wiley.andrew.j at gmail.com> wrote:

> On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer  
> <schveiguy at yahoo.com>wrote:
>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>
>> That's exactly what storing the interface in the object file does.  You
>> don't need the source because the object file contains the compiler's
>> interpretation of the source, and any inferred properties it has  
>> discovered.
>>
>
> Putting inferred purity into an object file sounds like a bad idea. It's
> not hard to imagine this scenario:
> -function foo in libSomething is inferred as pure (but not declared pure  
> by
> the author)
> -exeSomethingElse is compiled to use libSomething, and the compiler takes
> advantage of purity optimizations when calling foo
> -libSomething is recompiled and foo is no longer pure, and  
> exeSomethingElse
> silently breaks

no, it just doesn't link.

> Purity inference is fine for templates (because recompiling the library
> won't change the generated template code in an executable that depends on
> it), but in all other cases, the API needs to be exactly what the author
> declared it to be, or strange things will happen.

I agree that's the case with the current object/linker model.  Something  
that puts inferred properties into the object file needs a new model, one  
which does not blindly link code that wasn't compiled from the same  
sources.

-Steve