Unify tcx.constness query and param env constness checks
#102830
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
T-compiler
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @fee1-dead since I think I saw from |
|
After #101900 we'll be able to remove the constness from ParamEnv entirely, so not sure it's worth it doing anything with it. But seems fine to me either way. |
|
LGTM @bors r+ |
|
📌 Commit 01d566c8cb73c69d237d7fb41b2119d1f69efa8d has been approved by It is now in the queue for this repository. |
bors
added
S-waiting-on-bors
|
☔ The latest upstream changes (presumably #102850) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
added
S-waiting-on-author
compiler-errors
force-pushed
the
constness-parity
branch
from
01d566c
to
677e428
Compare
|
r=me once ci green |
This comment has been minimized.
This comment has been minimized.
compiler-errors
force-pushed
the
constness-parity
branch
from
677e428
to
c1c159f
Compare
|
@bors r=fee1-dead |
bors
added
S-waiting-on-bors
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Oct 10, 2022
…r=fee1-dead Unify `tcx.constness` query and param env constness checks The checks that we do in the `constness` query seem inconsistent with the checks that we do to determine if an item's param-env is const, so I merged them into the `constness` query and call that from the `param_env` query. I'm not sure if this totally makes sense -- is there a case where `tcx.param_env()` would return a const param-env for an item whose `tcx.constness()` is `Constness::NotConst`? Because if not, it seems a bit dangerous that these two differ. Luckily, not many places actually use `tcx.constness()`, and the checks in `tcx.param_env()` seem stricter than the checks in `tcx.constness()` (at least for the types of items we type-check). Also, due to the way that `tcx.param_env()` is implemented, it _never_ used to return a const param-env for a item coming from a different crate, which also seems dangerous (though also probably not weaponizable currently, because we seldom actually compute the param-env for a non-local item).
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Oct 10, 2022
…r=fee1-dead Unify `tcx.constness` query and param env constness checks The checks that we do in the `constness` query seem inconsistent with the checks that we do to determine if an item's param-env is const, so I merged them into the `constness` query and call that from the `param_env` query. I'm not sure if this totally makes sense -- is there a case where `tcx.param_env()` would return a const param-env for an item whose `tcx.constness()` is `Constness::NotConst`? Because if not, it seems a bit dangerous that these two differ. Luckily, not many places actually use `tcx.constness()`, and the checks in `tcx.param_env()` seem stricter than the checks in `tcx.constness()` (at least for the types of items we type-check). Also, due to the way that `tcx.param_env()` is implemented, it _never_ used to return a const param-env for a item coming from a different crate, which also seems dangerous (though also probably not weaponizable currently, because we seldom actually compute the param-env for a non-local item).
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Oct 11, 2022
…r=fee1-dead Unify `tcx.constness` query and param env constness checks The checks that we do in the `constness` query seem inconsistent with the checks that we do to determine if an item's param-env is const, so I merged them into the `constness` query and call that from the `param_env` query. I'm not sure if this totally makes sense -- is there a case where `tcx.param_env()` would return a const param-env for an item whose `tcx.constness()` is `Constness::NotConst`? Because if not, it seems a bit dangerous that these two differ. Luckily, not many places actually use `tcx.constness()`, and the checks in `tcx.param_env()` seem stricter than the checks in `tcx.constness()` (at least for the types of items we type-check). Also, due to the way that `tcx.param_env()` is implemented, it _never_ used to return a const param-env for a item coming from a different crate, which also seems dangerous (though also probably not weaponizable currently, because we seldom actually compute the param-env for a non-local item).
|
@bors r- failed in rollup |
bors
added
S-waiting-on-author
compiler-errors
force-pushed
the
constness-parity
branch
from
c1c159f
to
bef8681
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Oct 12, 2022
…r=fee1-dead Unify `tcx.constness` query and param env constness checks The checks that we do in the `constness` query seem inconsistent with the checks that we do to determine if an item's param-env is const, so I merged them into the `constness` query and call that from the `param_env` query. I'm not sure if this totally makes sense -- is there a case where `tcx.param_env()` would return a const param-env for an item whose `tcx.constness()` is `Constness::NotConst`? Because if not, it seems a bit dangerous that these two differ. Luckily, not many places actually use `tcx.constness()`, and the checks in `tcx.param_env()` seem stricter than the checks in `tcx.constness()` (at least for the types of items we type-check). Also, due to the way that `tcx.param_env()` is implemented, it _never_ used to return a const param-env for a item coming from a different crate, which also seems dangerous (though also probably not weaponizable currently, because we seldom actually compute the param-env for a non-local item).
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 12, 2022
Rollup of 7 pull requests Successful merges: - rust-lang#102623 (translation: eager translation) - rust-lang#102719 (Enforce alphabetical sorting with tidy) - rust-lang#102830 (Unify `tcx.constness` query and param env constness checks) - rust-lang#102883 (Fix stabilization of `feature(half_open_range_patterns)`) - rust-lang#102927 (Fix `let` keyword removal suggestion in structs) - rust-lang#102936 (rustdoc: remove unused CSS `nav.sum`) - rust-lang#102940 (Update books) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
albertlarsan68
added a commit
to albertlarsan68/rust
that referenced
this pull request
Oct 14, 2022
Rollup of 7 pull requests Successful merges: - rust-lang#102623 (translation: eager translation) - rust-lang#102769 (Clean up rustdoc startup) - rust-lang#102830 (Unify `tcx.constness` query and param env constness checks) - rust-lang#102847 (impl AsFd and AsRawFd for io::{Stdin, Stdout, Stderr}, not the sys versions) - rust-lang#102883 (Fix stabilization of `feature(half_open_range_patterns)`) - rust-lang#102936 (rustdoc: remove unused CSS `nav.sum`) - rust-lang#102940 (Update books) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 26, 2022
Revert "Unify tcx.constness and param env constness checks" Too much of a perf regression rust-lang#102975 (comment), and an attempt in rust-lang#103263 didn't fix it except for just a tiny bit. This change isn't really needed (see rust-lang#102830 (comment)), so this should be an easy revert.
RalfJung
pushed a commit
to RalfJung/miri
that referenced
this pull request
Oct 30, 2022
Revert "Unify tcx.constness and param env constness checks" Too much of a perf regression rust-lang/rust#102975 (comment), and an attempt in #103263 didn't fix it except for just a tiny bit. This change isn't really needed (see rust-lang/rust#102830 (comment)), so this should be an easy revert.
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this pull request
Jan 6, 2023
Rollup of 7 pull requests Successful merges: - rust-lang#102623 (translation: eager translation) - rust-lang#102719 (Enforce alphabetical sorting with tidy) - rust-lang#102830 (Unify `tcx.constness` query and param env constness checks) - rust-lang#102883 (Fix stabilization of `feature(half_open_range_patterns)`) - rust-lang#102927 (Fix `let` keyword removal suggestion in structs) - rust-lang#102936 (rustdoc: remove unused CSS `nav.sum`) - rust-lang#102940 (Update books) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The checks that we do in the
constnessquery seem inconsistent with the checks that we do to determine if an item's param-env is const, so I merged them into theconstnessquery and call that from theparam_envquery.I'm not sure if this totally makes sense -- is there a case where
tcx.param_env()would return a const param-env for an item whosetcx.constness()isConstness::NotConst? Because if not, it seems a bit dangerous that these two differ.Luckily, not many places actually use
tcx.constness(), and the checks intcx.param_env()seem stricter than the checks intcx.constness()(at least for the types of items we type-check).Also, due to the way that
tcx.param_env()is implemented, it never used to return a const param-env for a item coming from a different crate, which also seems dangerous (though also probably not weaponizable currently, because we seldom actually compute the param-env for a non-local item).