-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
querify layout and move param env out of the infcx #42189
Conversation
let type_desc = format!("{:?}", ty); | ||
let overall_size = layout.size(tcx); | ||
let align = layout.align(tcx); | ||
tcx.sess.code_stats.borrow_mut().record_type_size(kind, |
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 a bit of a hack but I can live with impure stats just like we have diagnostics.
@bors r+ |
📌 Commit 629812d has been approved by |
☔ The latest upstream changes (presumably #42245) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors r=eddyb |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 629812d has been approved by |
629812d
to
5977dc3
Compare
@bors r- Should be a quick fix, this is just the UI tests updating due to no longer being counted:
|
@bors r=eddyb |
📌 Commit 9b6baa5 has been approved by |
☔ The latest upstream changes (presumably #42276) made this pull request unmergeable. Please resolve the merge conflicts. |
🔒 Merge conflict |
9b6baa5
to
62e4733
Compare
@bors r=eddyb |
📌 Commit 62e4733 has been approved by |
querify layout and move param env out of the infcx The main goal of this PR is to move the parameter environment *out* of the inference context. This is because the inference environment will soon be changing over the course of inference --- for example, when we enter into a `for<'a> fn(...)` type, we will push a new environment with an increasing universe index, rather than skolemizing the `'a` references. Similarly, each obligation will soon be able to have a distinct parameter environment, and therefore the `Obligation` struct is extended to carry a `ParamEnv<'tcx>`. (I debated about putting it into the cause; seems plausible, but also weird.) Along the way, I also reworked how layout works, moving the layout cache into a proper query along the lines of needs-drop and friends. Finally, tweaks the inference context API. It seemed to be accumulating parameters at an alarming rate. The main way to e.g. make a subtype or equality relationship is to do the following: infcx.at(cause, param_env).sub(a, b) infcx.at(cause, param_env).eq(a, b) In both cases, `a` is considered the "expected" type (this used to be specified by a boolean). I tried hard to preserve the existing notion of what was "expected", although in some cases I'm not convinced it was being set on purpose one way or the other. This is why in some cases you will see me do `sup(b, a)`, which is otherwise equivalent to `sub(a, b)`, but sets the "expected type" differently. r? @eddyb cc @arielb1
💔 Test failed - status-travis |
@bors retry
|
☔ The latest upstream changes (presumably #42348) made this pull request unmergeable. Please resolve the merge conflicts. |
62e4733
to
952bc4b
Compare
tfw you rebase something and, by the time you're done, there's another conflict |
now we grow the type-sizes info during execution, rather than walking the cache after the fact
952bc4b
to
84047db
Compare
@bors r=eddyb |
📌 Commit 84047db has been approved by |
querify layout and move param env out of the infcx The main goal of this PR is to move the parameter environment *out* of the inference context. This is because the inference environment will soon be changing over the course of inference --- for example, when we enter into a `for<'a> fn(...)` type, we will push a new environment with an increasing universe index, rather than skolemizing the `'a` references. Similarly, each obligation will soon be able to have a distinct parameter environment, and therefore the `Obligation` struct is extended to carry a `ParamEnv<'tcx>`. (I debated about putting it into the cause; seems plausible, but also weird.) Along the way, I also reworked how layout works, moving the layout cache into a proper query along the lines of needs-drop and friends. Finally, tweaks the inference context API. It seemed to be accumulating parameters at an alarming rate. The main way to e.g. make a subtype or equality relationship is to do the following: infcx.at(cause, param_env).sub(a, b) infcx.at(cause, param_env).eq(a, b) In both cases, `a` is considered the "expected" type (this used to be specified by a boolean). I tried hard to preserve the existing notion of what was "expected", although in some cases I'm not convinced it was being set on purpose one way or the other. This is why in some cases you will see me do `sup(b, a)`, which is otherwise equivalent to `sub(a, b)`, but sets the "expected type" differently. r? @eddyb cc @arielb1
☀️ Test successful - status-appveyor, status-travis |
The main goal of this PR is to move the parameter environment out of the inference context. This is because the inference environment will soon be changing over the course of inference --- for example, when we enter into a
for<'a> fn(...)
type, we will push a new environment with an increasing universe index, rather than skolemizing the'a
references. Similarly, each obligation will soon be able to have a distinct parameter environment, and therefore theObligation
struct is extended to carry aParamEnv<'tcx>
. (I debated about putting it into the cause; seems plausible, but also weird.)Along the way, I also reworked how layout works, moving the layout cache into a proper query along the lines of needs-drop and friends.
Finally, tweaks the inference context API. It seemed to be accumulating parameters at an alarming rate. The main way to e.g. make a subtype or equality relationship is to do the following:
In both cases,
a
is considered the "expected" type (this used to be specified by a boolean). I tried hard to preserve the existing notion of what was "expected", although in some cases I'm not convinced it was being set on purpose one way or the other. This is why in some cases you will see me dosup(b, a)
, which is otherwise equivalent tosub(a, b)
, but sets the "expected type" differently.r? @eddyb
cc @arielb1