[GSoC] 'Replace Runtime Hooks with Templates' progress and update thread
Dan Printzell
xwildn00bx at gmail.com
Tue Jun 11 23:19:27 UTC 2019
On Tuesday, 28 May 2019 at 10:47:03 UTC, Dan Printzell wrote:
> [...]
I forgot to post the updates after week one due to school and
development, so here is my updates for week one and two.
Week 1
======
This week
~~~~~~~~~
- Turned `_d_arrayappendT` and `_d_arrayappendcTX`, with their
`*Trace`
function into templates.
- `_d_arrayappendcd` and `_d_arrayappendcd` where left alone as
they
are wrapper around the `_d_arrayappendT` for when assigning a
dchar
to char[], and dchar to wchar[], respectively.
- Started working on the dmd code.
- Got the lowering code working.
- Currently battling with the CTFE.
- I started with the templates inside object.d but then moved
them to
rt/lifetime.d and did a `public import` inside object.d
instead. I did
this because I started getting template recursions problems
when I use
`externDFunc`, as it used string concatenations internally. I
can
probably later move it back to object.d if needed later when I
get the
CTFE code working again.
Next week
~~~~~~~~~
- Continue with the dmd patches and get it be able to compile.
- Submit both the druntime and the dmd PR for review.
Blockers
~~~~~~~~
In the beginning I tried to translate the hook and all of the
functions
it called to templates. This just got me into a wormhole of needed
changes, and it would have made the PRs harder to review. So I
restarted
from scratch and instead only translated the entrypoints of each
hook,
and then internally use `typeid(T)` to pass to the function
underneath. Future work when all hooks are translated, could be to
translate the functions underneath, when applicable.
When I got the hook lowering working I realized how much the
hooks have
lied about their safety. So I had to add a `@trusted` wrapper
that fakes
`pure nothrow` for the hook to not break all code. [1]
As mentioned above, I'm currently battling with the CTFE to
understand
my lowered hooks. I found examples of this is done for
`__ArrayPostblit`
and `__ArrayDtor` inside dinterpret.d, and I will try and
understand how
they do it and implement the same for my hooks.
Week 2
======
This week
~~~~~~~~~
- I continued to work on the code to a state were I felt I could
start
to get some feedback, even if the code was not in a working
state.
- I got the CTFE 'intercept' code working so the hooks are now
using the
dinterpret.d code instead.
- Submitted work-in-progress PRs
- druntime: [https://github.com/dlang/druntime/pull/2632]
- dmd: [https://github.com/dlang/dmd/pull/9982]
Next week
~~~~~~~~~
- I still need to get the PR into a working and mergeable state,
I will
try and get this done as soon as possible.
- I need to implement unittests for the dmd patches to verify
that the
lowering code works as expected, both for the non-trace and
trace
versions.
- When waiting for reviews I will work on the conversion of
_d_array{setctor,ctor,cat*}, as according to my proposal
document.
- I will try to get a PR of this submitted earlier than what I
did the
previous ones. This should be possible as these functions are
simpler
than the last ones and now I know that I should not try and
translate
dependencies and instead just add `typeid(T)` whenever
necessary.
Blockers
~~~~~~~~
I've had compilation problem related to the translation of
_d_arrayappendcTX. I fixed this by instead calling the TypeInfo
version
of that function.
Due to the exam and school I was not able to finish what I
allocated
according to my proposal.
Currently I just have small bug where I trigger the postblit one
too
many times with assigning a single element `arr ~= structVar`.
This is
because the old backend code assigned the element outside of the
_d_arrayappend call, verses me now doing it internally. I
probably just
need to need to make sure that it always lowerest the `structVar`
into a
ref-able form, or make it assign the variable outside the hook
again.
Footnotes
======
[1]
[https://github.com/Vild/druntime/blob/8f72a8b25f02653445e1b8288583788711b87595/src/rt/lifetime.d#L2871-L2876]
More information about the Digitalmars-d
mailing list