Uh oh!
There was an error while loading. Please reload this page.
querify layout and move param env out of the infcx - #42189
Conversation
There was a problem hiding this comment.
This is a bit of a hack but I can live with impure stats just like we have diagnostics.
eddyb
commented
May 25, 2017
@bors r+ |
bors
commented
May 25, 2017
📌 Commit 629812d has been approved by |
bors
commented
May 26, 2017
☔ The latest upstream changes (presumably #42245) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
commented
May 26, 2017
@bors r=eddyb |
bors
commented
May 26, 2017
💡 This pull request was already approved, no need to approve it again.
|
bors
commented
May 26, 2017
📌 Commit 629812d has been approved by |
629812d to
5977dc3CompareMark-Simulacrum
commented
May 26, 2017
@bors r- Should be a quick fix, this is just the UI tests updating due to no longer being counted: |
nikomatsakis
commented
May 27, 2017
@bors r=eddyb |
bors
commented
May 27, 2017
📌 Commit 9b6baa5 has been approved by |
bors
commented
May 28, 2017
☔ The latest upstream changes (presumably #42276) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
commented
May 30, 2017
🔒 Merge conflict |
9b6baa5 to
62e4733Comparenikomatsakis
commented
May 30, 2017
@bors r=eddyb |
bors
commented
May 30, 2017
📌 Commit 62e4733 has been approved by |
bors
commented
May 30, 2017
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
bors
commented
May 30, 2017
💔 Test failed - status-travis |
Mark-Simulacrum
commented
May 30, 2017
@bors retry
|
bors
commented
Jun 1, 2017
☔ The latest upstream changes (presumably #42348) made this pull request unmergeable. Please resolve the merge conflicts. |
62e4733 to
952bc4bComparenikomatsakis
commented
Jun 1, 2017
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
84047dbComparenikomatsakis
commented
Jun 1, 2017
@bors r=eddyb |
bors
commented
Jun 1, 2017
📌 Commit 84047db has been approved by |
bors
commented
Jun 2, 2017
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
bors
commented
Jun 2, 2017
☀️ 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'areferences. Similarly, each obligation will soon be able to have a distinct parameter environment, and therefore theObligationstruct 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,
ais 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