RFC: Move runtime hook definitions to a .di file in druntime

[Iain Buclaw via D.gnu]

On 11 October 2014 07:59, Mike via D.gnu <d.gnu at puremagic.com> wrote:
> Hello,
>
> In my continued, though stalled, effort to try and make minimal runtime for
> embedded systems, I've tried to find a way for users to know at compile-time
> if a feature of the runtime is supported or not, and more importantly, if
> they are explicitly or implicitly using an unsupported feature.
>
> I'm not really in favor of adding a lot of compiler switches that create a
> new dialect of the language, though I'd take it if it were the only way.
> I'd rather have druntime inform the compiler what is or isn't supported, and
> avoid compiler changes.
>
> I've recently realized that druntime doesn't really have to be any different
> than other libraries: if a function isn't supported it simply isn't declared
> in the library's headers. If users make use of the undeclared function,
> explicitly or implicity, they get a compiler error, just like they would
> with any other library.  Currently these library hooks are all declared in
> d-codegen.cc
> (https://github.com/D-Programming-GDC/GDC/blob/9a05197e64031b96fda72a4428e9bb9b7e37ff01/gcc/d/d-codegen.cc)
> and documented at http://wiki.dlang.org/Runtime_Hooks
>
> So, I'm wondering if the compiler maintainers would entertain a change to
> the GDC that moved the runtime declarations (i.e. _d_newclass,
> _d_{whatever}) to a .di file in druntime.
> * Compilation would automatically import this header.
> * The compiler would throw an undefined identifier error if it needs to make
> a call to a runtime hook that isn't declared.
> * The.di file could be object.di, since it seems to have already become the
> site for anything to be implicitly imported, but it doesn't have to be.
>
> Of course there would have to be changes to the compiler to implement this
> idea, but I think it would be completely transparent to users.
>
> Advantages:
> * It will make it easier to implement a more polished minimal druntime, a "D
> as a better C", or some other variation of the language without having to
> resort to compiler changes.  Such a runtime has been asked for several times
> on these forums and even proposed by Walter.  This change won't eliminate
> calls for certain compiler switches, but it will provide developers with a
> few more tools to hopefully avoid them.
>
> * It makes the language more consistent.  Runtime hooks could become less
> "special" to the language and the compiler, and can be treated just like any
> other library function: If the declaration doesn't exist, compiler error.
>
> * Runtime hooks can be easily decorated with @deprecated or other attributes
> and enable several techniques to test language changes without having to
> rebuild the compiler.
>
> Thanks for your thoughtful consideration,
>
> Mike

Seems reasonable, and though such a thing may be advantageous on some
levels,I believe in the fairness of balance there should be a fair
counter argument before drawing up a conclusion.

Disadvantages:

* The runtime hooks in the *.di file must still match the signature
the compiler expects it to be.  In one essence this doesn't loosen the
separation between compiler and runtime, it instead makes it more
fragile if someone get's their forked version of the runtime hooks
wrong.

* Possibly extra semantic processing during the mid-flight of codegen
may be required to verify that the parameters the compiler generates
to pass match the function declaration when generating the call
expression.  Ideally the backend should not have to do this.

* GDC applies certain special attributes to some runtime functions
that can't be applied in normal D code.  Currently only the following
associations apply:
 1. _d_assert and friends are marked as volatile because they will
never return normally.
 2. _d_allocmemory is marked as malloc, to allow the compile to
optimise more aggressively around inlined functions that create a
closure (this can save some needless allocation calls).


I'm not knocking this idea though.

Iain.