Defer reasoning about regions until after regionck #7187
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch makes error handling for region inference failures more uniform by not reporting *any* region errors until the reigon inference step. This requires threading through more information about what caused a region constraint, so that we can still give informative error messages. I have only taken partial advantage of this information: when region inference fails, we still report the same error we always did, despite the fact that we now know precisely what caused the various constriants and what the region variable represents, which we did not know before. This change is required not only to improve error messages but because the region hierarchy is not in fact fully known until regionck, because it is not clear where closure bodies fit in (our current treatment is unsound). Moreover, the relationships between free variables cannot be fully determined until type inference is otherwise complete. cc rust-lang#3238.
common supertypes. This was breaking with the change to regions because of the (now incorrect) assumpton that our inference code makes, which is that if a <: b succeeds, there is no need to compute the LUB/GLB.
thestinger
added a commit
that referenced
this pull request
Jul 2, 2013
…-about-regions Defer reasoning about regions until after regionck
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jun 3, 2021
…p1995,phansch Add avoid_breaking_exported_api config option changelog: Add `avoid_breaking_exported_api` config option for [`enum_variant_names`], [`large_types_passed_by_value`], [`trivially_copy_pass_by_ref`], [`unnecessary_wraps`], [`upper_case_acronyms`] and [`wrong_self_convention`]. changelog: Deprecates [`pub_enum_variant_names`] and [`wrong_pub_self_convention`] as the non-pub variants are now configurable. changelog: Fix various false negatives for `pub` items that are not exported from the crate. A couple changes to late passes in order to use `cx.access_levels.is_exported` rather than `item.vis.kind.is_pub`. I'm not sure how to better document the config option or lints that are (not) affected (see comments in rust-lang#6806). Suggestions are welcome. cc `@rust-lang/clippy` I added `/clippy.toml` to use the config internally and `/tests/clippy.toml` to maintain a default config in ui tests. Closes rust-lang#6806 Closes rust-lang#4504
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This addresses issue #3238. It will also (in the future) enable more specific error messages for region inference failures, though I don't do much with that in this commit.
See first commit for details and brief motivation.
You may want to begin with the last commit, which adds some documentation explaining in a bit more detail some of the issues that arise when trying to handle closures. The docs include some material on how inference will handle closure bounds, though that code is not yet written (hoping to tackle that next).
r? @pcwalton (or anyone, but I guess you are the most versed in the code in question)