More robust handling of missing imported variables #131
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.
When building parts of the Jane Street tree problems were found with imported variables from missing
.cmx
files. The kinds of such variables are not known. This is already handled in various places, but one more in particular needed dealing with: the new code relating to depth variables occurring free in the types of closure variables.This patch removes the few uses of
DE.find_variable
(which always provided "don't know the kind" toTE.find
) in favour of callingTE.find
directly. Then all places that look up types in the environment have to identify whether the kind is known -- and be prepared for an error if it is not, and the.cmx
is missing. Then the patch adds logic specifically for the above case: if the kind is unknown for any variable involved in the type of a closure variable, the whole closure variable is marked as "degraded" and given typeUnknown
. This should be a rare situation.This can be reviewed later as part of the Flambda 2 review process.
cc @lthls @lukemaurer