work towards chalkify-ing the engine#49837
Conversation
|
D'oh, have to rebase =) |
|
@bors delegate=scalexm |
|
✌️ @scalexm can now approve this pull request |
src/librustc_driver/driver.rs
Outdated
There was a problem hiding this comment.
I must admit that when writing this code, I just put the compiler pass at the end of the function without thinking too much about it. What's the precise reason for preferring it to be placed before "death checking" etc?
There was a problem hiding this comment.
ah, it's a subtle thing. when you invoke check_name to test the name of an attribute, you also implicitly mark the attribute as "used" (at least by default):
Lines 208 to 214 in 43e994c
this info is then used by the "unused attribute" lint. Since we were running this pass before the lint fired, that info was not available when the unused attribute lint executed, producing lint warnings of "unused attribute" in some cases (only the new tests).
There was a problem hiding this comment.
that whole scheme needs to be rewritten for the query system at some point...
src/librustc_traits/lowering.rs
Outdated
There was a problem hiding this comment.
I think this is good, we should be able to retrieve all the clauses that are of interest to us. One point though, we will want to run this algorithm not only for our environment, but also for goals we want to prove, e.g.:
impl<T: Clone> Clone for Vec<T> { ... }
// Implemented(Vec<T>: Clone) :- Implemented(T: Clone) (*)
fn foo<T: Clone>(a: Vec<T>) {
// it doesn't seem like the `T: Clone` in the environment will enable us to reach
// the (*) rule above
// We must prove `Implemented(Vec<T>: Clone)` here: if we run the transitive
// closure algorithm for this goal, we will reach the (*) rule
let b = a.clone();
}so could we just change the name program_clauses_for_env to something more general? Like program_clauses_for_goals?
There was a problem hiding this comment.
I was debating about this-- specifically, what the key for the query should be, and how we should cache this information. I was sort of assuming that there would be some higher-level procedure that was, given a goal and its environment, assembling the full set of clauses (and caching the result, no doubt). Therefore, I figured this "for-env" query would just be a small part of it.
|
this is cool 👍🏻 |
|
I'll try to rebase today. |
05a7d9e to
e2f3781
Compare
|
rebased |
|
@bors r+ |
|
📌 Commit e2f3781 has been approved by |
|
☔ The latest upstream changes (presumably #49558) made this pull request unmergeable. Please resolve the merge conflicts. |
a61da9a to
d8c6d03
Compare
|
Rebased. However, the final results look a bit funny: In particular: but I don't think that is a problem that is due to this PR... I didn't investigate yet. |
|
☔ The latest upstream changes (presumably #49800) made this pull request unmergeable. Please resolve the merge conflicts. |
72869cb to
64c0247
Compare
|
@bors r=scalexm |
|
📌 Commit 64c0247 has been approved by |
|
⌛ Testing commit 64c0247972adfae02d6a58d08d6e57e577b310aa with merge 04de83c7b7e488cfb82d61f022588551550dcd4d... |
Chalk wants to be able to pass these constraints around. Also, the form we were using in our existing queries was not as general as we are going to need.
(rather than issuing multiple errors) Also, reorder so that the annotations are considered "used" when the lint runs.
This computes the transitive closure of traits that appear in the environment and then appends their clauses. It needs some work, but it's in the right direction.
Also, introduce `Clauses` and `Goals` type alises for readability.
a85943c to
2c5fbe2
Compare
|
@bors r=scalexm |
|
📌 Commit 2c5fbe2 has been approved by |
|
@bors p=3 |
work towards chalkify-ing the engine This work towards creating a "all program clauses needed for this goal" query r? @scalexm
|
☀️ Test successful - status-appveyor, status-travis |
| /// An associated type **declaration** (i.e., in a trait) | ||
| AssocTypeInTrait(InternedString), | ||
| /// An associated type **value** (i.e., in an impl) | ||
| AssocTypeInImpl(InternedString), |
There was a problem hiding this comment.
Why was this split done? Also, why "declaration vs value" and not "declaration vs definition"?
| match tcx.def_key(def_id).disambiguated_data.data { | ||
| DefPathData::Trait(_) => program_clauses_for_trait(tcx, def_id), | ||
| DefPathData::Impl => program_clauses_for_impl(tcx, def_id), | ||
| DefPathData::AssocTypeInImpl(..) => program_clauses_for_associated_type_value(tcx, def_id), |
There was a problem hiding this comment.
By "something in between DefPathData and Def" I meant "not Def itself" - ideally, a plain enum with no DefIds.
There was a problem hiding this comment.
Oh and Def should probably be renamed to Res(olution), as it's too specific to name resolution to deserve a more general name.
|
So... We could make |
|
The variants of |
|
@oli-obk @varkor My preferred solution would be to have That is, |
This work towards creating a "all program clauses needed for this goal" query
r? @scalexm