bug#34322: reproducibility: absolute file name in tramp.elc

[Stefan Monnier]

>> Here you can see that there is no nested bytecode object (i.e. no
>> #[...] with the main #[...]) so the call has been correctly inlined.
> Given, that the absolute file name is not needed in the bytecode,

It's present in the in-memory bytecode object so that `C-h f` can jump
to the source upon demand, so it is needed.

> I'm wondering why we insert it there.

It's because we just insert the bytecode object wholesale (not a copy of
the object), so it comes with all its fields.

> Couldn't we live without?

We'd have to make a copy of the bytecode object, skipping the
source-code reference.

But really, this is actually a side-problem: the inlined bytecode is not
spliced the way it should, so the inlining optimization is basically
missing.  Such a half-assed inlining gives you all the downsides of
inlining without its upsides.  Once we fix that, the reproducibility
problem will also be fixed.


        Stefan