-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compute type fragments left over from moves #17439
Compute type fragments left over from moves #17439
Conversation
…varId`. (This refactoring looks like a wash in this commit, in terms of overall code-cleanliness; but it makes things nicer in a future commit for static drop semantics.)
…ef and by-value captures. This is necessary to be able to properly backtrack in a loan-path to the definition site of the original variable (which I found necessary in later commits).
`LpDowncast` carries the `DefId` of the variant itself. To support this, added the enum variant `DefId` to the `cat_downcast` variant in `mem_categorization::categorization`.
To make this clean, refactored old `LoanPath` enum into a `LoanPath` struct with a `ty::t` and a newly-added `LoanPathVariant` enum. This enabled me to get rid of the ugly and fragile `LoanPath::to_type` method, and I can probably also get rid of other stuff that was supporting it, maybe.
This is accomplished by: 1. Add `MatchMode` enum to `expr_use_visitor`. 2. Computing the match mode for each pattern via a pre-pass, and then passing the mode along when visiting the pattern in expr_use_visitor. 3. Adding a `fn matched_pat` callback to expr_use_visitor, which is called on all nodes of the pattern (as opposed to `fn consume_pat`, which is only invoked for identifiers at the leaves of the pattern), and invoking it accordingly. Of particular interest are the `cat_downcast` instances established when matching enum variants.
Note that due to PR rust-lang#16053, we only actually deal with `a @ Var(_)` here, (as opposed to a hypothetical `a @ Var(ref b)`, which cannot currenty arise, and maybe will never be supported for non-copy data).
… a span. This will be utilized by the rustc_drop_obligations code-annotation-via-errors hack to print out the drop obligations that are removed at the end of scopes.
When you add `rustc_drop_obligations` as an annotation on a function, it will print all of the drop-obligation manipulations as individual compiler errors associated with the expressions that caused the effect on the drop obligation state. Surround drop-obligations in output with `` quotes to help unintended prefix matches Prints scope-end messages at end of their scope.
r? @nick29581 |
@@ -93,6 +93,10 @@ impl SpanHandler { | |||
self.handler.emit_with_code(Some((&self.cm, sp)), msg, code, Error); | |||
self.handler.bump_err_count(); | |||
} | |||
pub fn span_end_err(&self, sp: Span, msg: &str) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment here - not obvious what this fn does from the name
I started to review this, but it quickly because apparent that I don't know the borrow checker well enough to do it justice, so going to hand off the review, sorry. r? @nikomatsakis or @pcwalton |
// copied or moved depending on `mode`. Note that `matched_pat` | ||
// is called on all variant/structs in the pattern (i.e., the | ||
// interior nodes of the pattern's tree structure) while | ||
// consume_pat is called on the binding identifiers in the pattern |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you clarify whether BOTH matched_pat
and consume_pat
are called on leaves, or just one of them?
(temporarily closing pull request; I'm going to cut it down a little to remove more of the dataflow artifacts that can be left for a later PR.) |
…ykril Properly prime all crate def maps in parallel_prime_caches
Compute type fragments left over from moves.
This is part 1 of a pair of PRs that prepare for planned revisions to our drop implementation; this foundation is required for either "static drop semantics" (RFC PR 210) or for the improved dynamic drop semantics that uses an out-of-band bitfield on the stack to track which loan-paths still need to be dropped.
This PR deliberately leaves out the control-flow analysis changes that are actually necessary for the drop changes, which are in part 2. This is more fundamental stuff here.
(The commits are deliberately split up in an effort to ease reading these revisions; I do not plan to squash them.)