You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
trans: discrepancies between (MIR-based) collector and non-MIR translation. #34151
The translation item collector in trans::collector is supposed to find all monomorphizations and instantiations of local and extern functions and drop-glue that need to go into the binary currently being compiled. It does so by analyzing the MIR of every function, following calls, references, drops, etc.
In theory this is a sound strategy.
However, in combination with legacy-trans, which is not based on MIR, we are running into problems: Since the MIR is heavily optimized before being passed into the collector, it might not contain references to what really is dead code. HIR-based trans, however, does not have this knowledge and will have to translate everything. This leads to situations where HIR-based trans will insert references to what only MIR-based analysis knows to be dead code. Thus we end up with "dangling references" and, subsequently, linker errors.
In order to still support HIR-based trans for the time being, there's some code in trans that will instantiate functions and drop-glue on demand if the collector "missed" it. This code should be removed once HIR-based trans has been removed from the compiler.
Specifically, this concerns trans::monomorphize::monomorphic_fn() and trans::glue::get_drop_glue_core().
You can just delete anything below that line in that function. The trickier part is finding out if this causes any breakage. If make check passes with the code removed, that would be a good indication that everything still works as expected. If you get that far you could make a PR and someone will do a crater run that will test the changes against even more code.
That means that the collector did not anticipate that drop-glue for this type would be needed. It's not entirely surprising that this happens to be a closure type. Closures are special in a few ways. This looks like the collector is missing the drop glue because it is only accessed via the closures vtable.
Any ideas on how to fix it? Well, given that I don't really know what drop glue is (I assume it's code that calls the drop function on things when they go out of scope), it seems hard to fix. :)
Activity
trans: Enable falling back to on-demand instantiation for drop-glue a…
trans: Enable falling back to on-demand instantiation for drop-glue a…
trans: Enable falling back to on-demand instantiation for drop-glue a…
ahmedcharles commentedon Aug 27, 2016
@michaelwoerister Now that MIR is the only option, is this still relevant? And if so, what needs to be done?
eddyb commentedon Aug 27, 2016
Drop glue might still be needed, but on-demand monomorphizations are gone.
Somewhat relatedly, @arielb1 has expressed interest in working on making the collector generate MIR bodies for all the needed shims and drop glues.
michaelwoerister commentedon Aug 29, 2016
The code for instantiating it on demand is still there, but it should not be needed anymore.
ahmedcharles commentedon Aug 29, 2016
Is there a pointer for what likely needs removing if I wanted to do this?
michaelwoerister commentedon Aug 29, 2016
@ahmedcharles The relevant code is here:
rust/src/librustc_trans/glue.rs
Line 227 in 86dde9b
You can just delete anything below that line in that function. The trickier part is finding out if this causes any breakage. If
make checkpasses with the code removed, that would be a good indication that everything still works as expected. If you get that far you could make a PR and someone will do a crater run that will test the changes against even more code.ahmedcharles commentedon Aug 30, 2016
I removed the code, changed the debug! to a panic! and got this:
michaelwoerister commentedon Aug 30, 2016
That means that the collector did not anticipate that drop-glue for this type would be needed. It's not entirely surprising that this happens to be a closure type. Closures are special in a few ways. This looks like the collector is missing the drop glue because it is only accessed via the closures vtable.
eddyb commentedon Aug 30, 2016
Could be from
rustc_trans::closure::trans_fn_once_adapter_shimscheduling a closure drop.This is where @arielb1's plans for generating shim/glue MIR would come in real handy.
michaelwoerister commentedon Aug 30, 2016
Yes, that would remove some special cases from the collector.
ahmedcharles commentedon Aug 30, 2016
Any ideas on how to fix it? Well, given that I don't really know what drop glue is (I assume it's code that calls the drop function on things when they go out of scope), it seems hard to fix. :)
eddyb commentedon Aug 30, 2016
@arielb1 wants to fix this by generating MIR for those cases as-needed. Don't think there's a much simpler solution.
michaelwoerister commentedon Nov 9, 2016
old-trans is gone 🎉