Well, I had a patch all ready, but when writing it up, I discovered the logic
behind comment #26 is wrong. Specifically, Jason's proto-patch makes the
fn_copy_table GCable, but keeps the constexpr_call_table GC-deletable. The
logic is that if we need to recreate a particular constexpr call, we'll have a
body available so not need to do another copy. But consider a constexpr such as:
constexpr int Foo (int i) { return i ? Foo (i - 1) : 0; }
Then the following evaluations:
Foo (0)
<possible GC>
Foo (1)
If the GC does not happen, we'll have cached the evaluation of 'Foo(0)', and so
not need to reevaluate it during the 'Foo(1)' call. The evaluation of 'Foo(1)'
will use the single cached body of Foo for it's own evaluation, so no additional
cloning will happen.
However, if the GC does happen, we'll need to evaluate 'Foo(0)' again, but
there'll be no cached body of Foo available (it being in use for 'Foo(1)'). So
we will observe a UID change.
I think that means the constexpr_call_table must be preserved too. Something
along the lines of the size checking I posted yesterday? (but with the GTY stuff
done better).
nathan
