On Wed, Jan 08, 2014 at 01:57:21AM +0000, Adam D. Ruppe wrote: [...]
> Anywho, let me get it back to the whole "minimal" thing....
> 
> But put a single struct and it complains
> Error: TypeInfo not found. object.d may be incorrectly installed or
> corrupt, compile with -v switch
> 
> 
> even with -betterC :-( :-( :-(
> 
> 
> I don't even care about typeinfo; doing my own runtime, I'd be ok with any function that needs it to simply fail to compile. I can do it myself with templates.

Couldn't you create some TypeInfo's with stubbed-out methods? Or does that not work either?


[...]
> >Even the switch...case statement seems to be, at least partially, implemented in the runtime
> 
> Yea, for strings. My thing did a stupid loop for string cases :P

Isn't that what the druntime string switch function does too? :-P Last I checked, it was also using a linear search through the cases.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and those who can't.

On 2014-01-08 02:57, Adam D. Ruppe wrote:

> But put a single struct and it complains
> Error: TypeInfo not found. object.d may be incorrectly installed or
> corrupt, compile with -v switch
>
>
> even with -betterC :-( :-( :-(

Even if the struct isn't used or void-initialized?

-- 
/Jacob Carlborg

On Wednesday, 8 January 2014 at 01:15:45 UTC, Iain Buclaw wrote:
>> Anyway, once you add the word "class" or "struct" you release an avalanche
>> of snowballing required runtime stuff that you are likely not even using,
>> directly or indirectly, in your program. And if using --gc-sections in your
>> linker, it all just gets stripped out in the end. I was trying to articulate
>> that here (http://forum.dlang.org/post/zewevdmburppufkjxdje@forum.dlang.org)
>>
>
> If you use a struct, it generates typeinfo and initialiser symbols
> that go on the comdat on the basis that you *may* access the typeinfo
> at runtime.
>
> These are weak decls so the linker merges/removes duplicates.  There's
> currently no solution in which the compiler decides whether to omit
> sending the symbols to object file, but this can be worked upon.
>

Thanks Iain, things are starting to make sense.

Can't the compiler just emit whatever the runtime provides for the TypeInfo stuff, right or wrong?  So, if the runtime does not provide a TypeInfo_x implementation, it doesn't emit one.  If the runtime does provide a TypeInfo_x, it emits exactly what the runtime provided, right or wrong.

If the runtime only provides some TypeInfo_x implementations and not others, the compiler only emits the ones that it finds.

If the program provides a faulty TypeInfo_x implementation, the program behaves in a faulty manner, just as the programmer specified.

If the program references a missing TypeInfo_x (or one of it's properties) implicitly/indirectly, the linker will emit and undefined reference error, won't it?

Is this implementation possible?

On 8 January 2014 11:13, Mike <none@none.com> wrote:
> On Wednesday, 8 January 2014 at 01:15:45 UTC, Iain Buclaw wrote:
>>>
>>> Anyway, once you add the word "class" or "struct" you release an
>>> avalanche
>>> of snowballing required runtime stuff that you are likely not even using,
>>> directly or indirectly, in your program. And if using --gc-sections in
>>> your
>>> linker, it all just gets stripped out in the end. I was trying to
>>> articulate
>>> that here
>>> (http://forum.dlang.org/post/zewevdmburppufkjxdje@forum.dlang.org)
>>>
>>
>> If you use a struct, it generates typeinfo and initialiser symbols that go on the comdat on the basis that you *may* access the typeinfo at runtime.
>>
>> These are weak decls so the linker merges/removes duplicates.  There's currently no solution in which the compiler decides whether to omit sending the symbols to object file, but this can be worked upon.
>>
>
> Thanks Iain, things are starting to make sense.
>
> Can't the compiler just emit whatever the runtime provides for the TypeInfo stuff, right or wrong?  So, if the runtime does not provide a TypeInfo_x implementation, it doesn't emit one.  If the runtime does provide a TypeInfo_x, it emits exactly what the runtime provided, right or wrong.
>
> If the program provides a faulty TypeInfo_x implementation, the program behaves in a faulty manner, just as the programmer specified.
>
> If the program references a missing TypeInfo_x (or one of it's properties) implicitly/indirectly, the linker will emit and undefined reference error, won't it?
>
> Is this implementation possible?
>
>

Half and half. The TypeInfo support code is a separation layer between runtime and compiler and the compiler is not fully aware of what is implemented by runtime.

On the one hand, there's the internal TypeInfo you see in object.d,
these are required to be known at compile time for certain operations.
 If those aren't present then you'll get mismatch errors from the
compiler, and in the case of GDC, a handy little ICE to end the
compilation immediately.

On the other hand there's the TypeInfo support under rt.typeinfo (eg: TypeInfo_AC).  For these, only the symbol is generated by the compiler on the fly and referenced as 'extern'. So you get linker errors if they aren't implemented.

This is why I suggested the 'all or nothing' approach.

On 8 January 2014 12:13, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 8 January 2014 11:13, Mike <none@none.com> wrote:
>> On Wednesday, 8 January 2014 at 01:15:45 UTC, Iain Buclaw wrote:
>>>>
>>>> Anyway, once you add the word "class" or "struct" you release an
>>>> avalanche
>>>> of snowballing required runtime stuff that you are likely not even using,
>>>> directly or indirectly, in your program. And if using --gc-sections in
>>>> your
>>>> linker, it all just gets stripped out in the end. I was trying to
>>>> articulate
>>>> that here
>>>> (http://forum.dlang.org/post/zewevdmburppufkjxdje@forum.dlang.org)
>>>>
>>>
>>> If you use a struct, it generates typeinfo and initialiser symbols that go on the comdat on the basis that you *may* access the typeinfo at runtime.
>>>
>>> These are weak decls so the linker merges/removes duplicates.  There's currently no solution in which the compiler decides whether to omit sending the symbols to object file, but this can be worked upon.
>>>
>>
>> Thanks Iain, things are starting to make sense.
>>
>> Can't the compiler just emit whatever the runtime provides for the TypeInfo stuff, right or wrong?  So, if the runtime does not provide a TypeInfo_x implementation, it doesn't emit one.  If the runtime does provide a TypeInfo_x, it emits exactly what the runtime provided, right or wrong.
>>
>> If the program provides a faulty TypeInfo_x implementation, the program behaves in a faulty manner, just as the programmer specified.
>>
>> If the program references a missing TypeInfo_x (or one of it's properties) implicitly/indirectly, the linker will emit and undefined reference error, won't it?
>>
>> Is this implementation possible?
>>
>>
>
> Half and half. The TypeInfo support code is a separation layer between runtime and compiler and the compiler is not fully aware of what is implemented by runtime.
>
> On the one hand, there's the internal TypeInfo you see in object.d,
> these are required to be known at compile time for certain operations.
>  If those aren't present then you'll get mismatch errors from the
> compiler, and in the case of GDC, a handy little ICE to end the
> compilation immediately.
>
> On the other hand there's the TypeInfo support under rt.typeinfo (eg: TypeInfo_AC).  For these, only the symbol is generated by the compiler on the fly and referenced as 'extern'. So you get linker errors if they aren't implemented.
>
> This is why I suggested the 'all or nothing' approach.

Note, the struct of the internal TypeInfo symbols are known at compile time because object.d is implicitly imported.

On 8 January 2014 12:14, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 8 January 2014 12:13, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> On 8 January 2014 11:13, Mike <none@none.com> wrote:
>>> On Wednesday, 8 January 2014 at 01:15:45 UTC, Iain Buclaw wrote:
>>>>>
>>>>> Anyway, once you add the word "class" or "struct" you release an
>>>>> avalanche
>>>>> of snowballing required runtime stuff that you are likely not even using,
>>>>> directly or indirectly, in your program. And if using --gc-sections in
>>>>> your
>>>>> linker, it all just gets stripped out in the end. I was trying to
>>>>> articulate
>>>>> that here
>>>>> (http://forum.dlang.org/post/zewevdmburppufkjxdje@forum.dlang.org)
>>>>>
>>>>
>>>> If you use a struct, it generates typeinfo and initialiser symbols that go on the comdat on the basis that you *may* access the typeinfo at runtime.
>>>>
>>>> These are weak decls so the linker merges/removes duplicates.  There's currently no solution in which the compiler decides whether to omit sending the symbols to object file, but this can be worked upon.
>>>>
>>>
>>> Thanks Iain, things are starting to make sense.
>>>
>>> Can't the compiler just emit whatever the runtime provides for the TypeInfo stuff, right or wrong?  So, if the runtime does not provide a TypeInfo_x implementation, it doesn't emit one.  If the runtime does provide a TypeInfo_x, it emits exactly what the runtime provided, right or wrong.
>>>
>>> If the program provides a faulty TypeInfo_x implementation, the program behaves in a faulty manner, just as the programmer specified.
>>>
>>> If the program references a missing TypeInfo_x (or one of it's properties) implicitly/indirectly, the linker will emit and undefined reference error, won't it?
>>>
>>> Is this implementation possible?
>>>
>>>
>>
>> Half and half. The TypeInfo support code is a separation layer between runtime and compiler and the compiler is not fully aware of what is implemented by runtime.
>>
>> On the one hand, there's the internal TypeInfo you see in object.d,
>> these are required to be known at compile time for certain operations.
>>  If those aren't present then you'll get mismatch errors from the
>> compiler, and in the case of GDC, a handy little ICE to end the
>> compilation immediately.
>>
>> On the other hand there's the TypeInfo support under rt.typeinfo (eg: TypeInfo_AC).  For these, only the symbol is generated by the compiler on the fly and referenced as 'extern'. So you get linker errors if they aren't implemented.
>>
>> This is why I suggested the 'all or nothing' approach.
>
> Note, the struct of the internal TypeInfo symbols are known at compile time because object.d is implicitly imported.

s/struct/structure/

On Wednesday, 8 January 2014 at 06:10:38 UTC, H. S. Teoh wrote:
> Couldn't you create some TypeInfo's with stubbed-out methods?

Not quite, see Iain's post, it is half and half. The compiler checks the runtime definition to ensure it is there and the correct size, so you can sorta stub it (my minimal.zip did a void*[16]) but it still takes some care. And the compiler outputs the data anyway, so you might as well define it correctly and actually use it.

On Wednesday, 8 January 2014 at 07:57:29 UTC, Jacob Carlborg
wrote:
> Even if the struct isn't used or void-initialized?

Yeah.

Am Wed, 8 Jan 2014 01:15:32 +0000
schrieb Iain Buclaw <ibuclaw@gdcproject.org>:

> 
> If you use a struct, it generates typeinfo and initialiser symbols that go on the comdat on the basis that you *may* access the typeinfo at runtime.
> 
> These are weak decls so the linker merges/removes duplicates.  There's currently no solution in which the compiler decides whether to omit sending the symbols to object file, but this can be worked upon.

I think there are three steps to make TypeInfo completely optional

* -fno-typeinfo as a global switch instructing the compiler that it
  _never_ has typeinfo and should never output typeinfo. In this case
  all files must be compiled consistently with -fno-typeinfo or without
  it
  Useful to disable all TypeInfo generation even if the runtime has
  typeinfo support
* pragma(notypeinfo)/@attribute(notypeinfo) as in LDC
  Useful to exclude typeinfo for specific types
* A way for the runtime to say 'I don't support TypeInfo'
  Basically introducing 'core.config' with 'enum
  RuntimeSupportsTypeInfo = false;'. If the compiler finds this
  declaration it should automatically use '-fno-typeinfo'

'core.config' could then also be used with RuntimeSupportsGC, RuntimeSupportsUTF (switches over strings, IIRC) and similar things. A minimal runtime would just set all those variables to false and the compiler could automatically use a restricted set of D (nogc/no string switches/...)

> 
> I think the best logical steps to go down, is that you should write a
> replacement for the core library functions that the compiler
> implicitly calls (_d_arrayliteralX, _d_arraycopy, _d_newclass,
> _d_newitemT, etc), but omit using the TypeInfo parameter.  Once you
> feel that it is ready, then we can add a switch into the compiler
> that:
> 1) Doesn't generate typeinfo
> 2) Passes a null pointer as the typeinfo parameter to the Druntime
> library calls.
> 

> Object _d_newclass(const ClassInfo ci)  ->  Object _d_newclass()
> 
IIRC Andrei wants _d_newclass to be independent of ClassInfo anyway (by making it a template). I think this came up when we talked about replacing 'new' with a library template or in a custom allocator discussion or something.

There were already approaches making associative arrays a templated library type. Then we could just as well make normal arrays a templated library type and avoid typeinfo there.

Runtime variadic arguments need typeinfo IIRC. We'd have to ban calling those functions with -fno-typeinfo or if any of the arguments was declared with @attribute(notypeinfo)

Am Wed, 8 Jan 2014 12:13:33 +0000
schrieb Iain Buclaw <ibuclaw@gdcproject.org>:

> On 8 January 2014 11:13, Mike <none@none.com> wrote:
> > Can't the compiler just emit whatever the runtime provides for the TypeInfo stuff, right or wrong?  So, if the runtime does not provide a TypeInfo_x implementation, it doesn't emit one.  If the runtime does provide a TypeInfo_x, it emits exactly what the runtime provided, right or wrong.
> >
> > If the program provides a faulty TypeInfo_x implementation, the program behaves in a faulty manner, just as the programmer specified.
> >
> > If the program references a missing TypeInfo_x (or one of it's properties) implicitly/indirectly, the linker will emit and undefined reference error, won't it?
> >
> > Is this implementation possible?
> >
> >
> 
> Half and half. The TypeInfo support code is a separation layer between runtime and compiler and the compiler is not fully aware of what is implemented by runtime.
> 
> On the one hand, there's the internal TypeInfo you see in object.d,
> these are required to be known at compile time for certain operations.
>  If those aren't present then you'll get mismatch errors from the
> compiler, and in the case of GDC, a handy little ICE to end the
> compilation immediately.

However, the compiler does not actually parse and use the definitions in object.d. It always uses it's own hardcoded definitions. So you can't simply remove fields from the TypeInfo classes and then expect the compiler to stop outputting the data for this field.

Although the implementation could be changed to allow for that I don't think it's worth the trouble. I think if we can simply disable/enable TypeInfo that should be good enough. Having many different TypeInfo formats could bring it's own problems.