-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Implement (most of) RFC 1214 #27641
Implement (most of) RFC 1214 #27641
Conversation
The binary file |
Note to self: maybe restore the code that bans where clauses w/ no type parameters, even if it's not very useful? |
@@ -188,6 +189,8 @@ pub struct TypeTrace<'tcx> { | |||
/// See `error_reporting.rs` for more details | |||
#[derive(Clone, Debug)] | |||
pub enum SubregionOrigin<'tcx> { | |||
RFC1214Subregion(Rc<SubregionOrigin<'tcx>>), |
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.
Missing doc comment.
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.
This is temporary anyway, but still.
I would like to at least prevent where-clauses on non-generic methods - these will be translated anyway and cause ICEs when the obligations can't be fulfilled. |
@@ -273,7 +273,9 @@ enum PassArgs { | |||
impl<'d,'t,'a,'tcx> ExprUseVisitor<'d,'t,'a,'tcx> { | |||
pub fn new(delegate: &'d mut Delegate<'tcx>, | |||
typer: &'t infer::InferCtxt<'a, 'tcx>) | |||
-> ExprUseVisitor<'d,'t,'a, 'tcx> { | |||
-> ExprUseVisitor<'d,'t,'a,'tcx> | |||
where 'tcx: 't // FIXME(#27583) workaround apparent stage0 bug |
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.
any progress with the bug? I guess I can play with this after this lands.
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.
any progress with the bug? I guess I can play with this after this lands.
no, I haven't come back to it yet.
I think I will just restore the rules as they were, and write up a separate rfc to try and rationalize them. Niko -------- Original message -------- From: arielb1 notifications@github.com Date:08/10/2015 17:37 (GMT-05:00) To: rust-lang/rust rust@noreply.github.com Cc: Niko Matsakis niko@alum.mit.edu Subject: Re: [rust] Implement (most of) RFC 1214 (#27641) I would like to at least prevent where-clauses on non-generic methods - these will be translated anyway and cause ICEs when the obligations can't be fulfilled. — |
if is_warning { | ||
note_obligation_cause(infcx, obligation); | ||
} else if let Some(s) = custom_note { | ||
infcx.tcx.sess.span_note(obligation.cause.span, &s); |
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.
no note_obligation_cause
there?
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.
no note_obligation_cause there?
Debatable. I was thinking that the custom message plays the role of this note, but I guess they are potentially somewhat orthogonal.
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.
this really improves the error message for various "[u8] does not implement Sized"-s.
Thanks for the suggestions, @eefriedman and @arielb1. I'll be pushing some updates soon. Just debating about whether to switch from |
Sure, but a predicate is (I think) POD, so I wouldn't expect this to be hyper expensive. Of course |
It is. Could you just make it Copy? (you also need |
// regions. This is perhaps not ideal. | ||
self.from_object_ty(ty, data); | ||
|
||
// FIXME(#27579) RFC also considers adding trait |
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.
Couldn't we check the obligations with Self being the object type? i.e. if you have trait Foo<T> where T: Eq<Box<Self>>
, Foo<T> wf
would require that T: Eq<Box<Self>>
. I'm not sure how important is this, because (am I wrong here?) non-supertrait predicates are never elaborated and therefore can be safely ignored (up to #27675 anyway).
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.
Couldn't we check the obligations with Self being the object type?
Interesting thought. I'll have to think it over. It would certainly be nice if so. It may interact with the restrictions on object safety and #27675.
I'm not sure how important is this, because (am I wrong here?) non-supertrait predicates are never elaborated and therefore can be safely ignored
This is true but I have considered changing this (#20671).
I would also include a test for aturon's bug (#27592), if it is indeed fixed. |
☔ The latest upstream changes (presumably #27584) made this pull request unmergeable. Please resolve the merge conflicts. |
after we check casts, because sometimes casts can influence inference, unfortunately. We do re-run `select_all_trait_obligations` during regionck anyhow.
`implicator`. These definitions are also in accordance with RFC 1214 (or more so), and hence somewhat different from the implicator. This commit also modifies the implicator to remove the older rules for projections, which can easily trigger infinite loops.
on more kind of items
So I ran a crater run with a variant of @arielb1's proposed rules for handling projection outlines. In particular, these rules never (I think) introduce overly conservative constraints into the region graph; instead they run the risk of the region graph being underconstrained. I found two new failures versus previous runs, but those seem to be crates that have been newly introduced. One of the failures is due to #27834, which is a pre-existing issue. I have not yet diagnosed the second failure. |
OK, after investigating the other failure ( |
@bors r=nrc |
📌 Commit 7f8942c has been approved by |
the lifetime parameters on request ('a, 'b, 'k) seem to play the following roles: 'a, 'b -- these represent the processing of this individual request. They can vary. 'k -- this represents the lifetime of the server's internal, mutable storage. It is fixed. If you only have two parameters 'x and 'y to supply, then, the correct pattern is `'x, 'x, 'y`, because then `'x` plays the role of the intersection of `'a` and `'b`, but `'y` is pinned to the server's internal storage.
Author of combine here. Got a heads up from @nikomatsakis about this and it should be possible to fix easily. I will upload a fix once I can test it on nightly. |
This PR implements the majority of RFC 1214. In particular, it implements: - the new outlives relation - comprehensive WF checking For the most part, new code receives warnings, not errors, though 3 regressions were found via a crater run. There are some deviations from RFC 1214. Most notably: - we still consider implied bounds from fn ret; this intersects other soundness issues that I intend to address in detail in a follow-up RFC. Fixing this without breaking a lot of code probably requires rewriting compare-method somewhat (which is probably a good thing). - object types do not check trait bounds for fear of encountering `Self`; this was left as an unresolved question in RFC 1214, but ultimately feels inconsistent. Both of those two issues are highlighted in the tracking issue, #27579. #27579 also includes a testing matrix with new tests that I wrote -- these probably duplicate some existing tests, I tried to check but wasn't quite sure what to look for. I tried to be thorough in testing the WF relation, at least, but would welcome suggestions for missing tests. r? @nrc (or perhaps someone else?)
OK, I believe I have posted PRs for all broken crates, apart from combine, which I wasn't quite sure how best to fix. There are of course many others that received warnings -- I may try to fix some of those too. |
… from mw state Correct lifetimes in response to errors found by rust-lang/rust#27641; the lifetime parameters on request ('a, 'b, 'k) seem to play the following roles: 'a, 'b -- these represent the processing of this individual request. They can vary. 'k -- this represents the lifetime of the server's internal, mutable storage. It is fixed. If you only have two parameters 'x and 'y to supply, then, the correct pattern is `'x, 'x, 'y`, because then `'x` plays the role of the intersection of `'a` and `'b`, but `'y` is pinned to the server's internal storage.
… from mw state Correct lifetimes in response to errors found by rust-lang/rust#27641; the lifetime parameters on request ('a, 'b, 'k) seem to play the following roles: 'a, 'b -- these represent the processing of this individual request. They can vary. 'k -- this represents the lifetime of the server's internal, mutable storage. It is fixed. If you only have two parameters 'x and 'y to supply, then, the correct pattern is `'x, 'x, 'y`, because then `'x` plays the role of the intersection of `'a` and `'b`, but `'y` is pinned to the server's internal storage. BREAKING CHANGE: Most type signatures involving `Request` will have broken, to fix code broken by this change, you will need to remove the third lifetime.
Fix region errors uncovered by rust-lang/rust#27641
Update tendril to avoid double borrow. Update tendril to avoid double borrow. This double borrow is detected by the latest Nightly builds, or at least will be once rust-lang/rust#27641 makes it into such a build. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/tendril/18) <!-- Reviewable:end -->
This PR implements the majority of RFC 1214. In particular, it implements:
For the most part, new code receives warnings, not errors, though 3 regressions were found via a crater run.
There are some deviations from RFC 1214. Most notably:
Self
; this was left as an unresolved question in RFC 1214, but ultimately feels inconsistent.Both of those two issues are highlighted in the tracking issue, #27579. #27579 also includes a testing matrix with new tests that I wrote -- these probably duplicate some existing tests, I tried to check but wasn't quite sure what to look for. I tried to be thorough in testing the WF relation, at least, but would welcome suggestions for missing tests.
r? @nrc (or perhaps someone else?)