Perform FSA on a GC entry point's return type #143
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, when we encountered a GC FSA entry-point (e.g.
Gc::new
) we performed FSA on the argument type of that entry point. WhenGc::new
was our only entry point, this worked fine, because it would always resolve to theT
inGc<T>
.However, with the addition the of
Gc::from
conversion trait entry point, we can end up being overly conservative with FSA for no good reason. Consider the following:Where the argument type to this entry-point is
Box<HasRef>
, but the actual constructedGc
type isGc<HasRef>
. Using our previous approach, we would have to perform FSA onBox<HasRef>
, even though theBox
is never used in the context of GC. On large codebases, this lead to FSA rejecting soundGc<T>
s.This commit therefore tweaks FSA to check the return type of an entry-point, which should always be some
Gc<T>
(we assert! this, because if it isn't, something has gone very wrong.)