about summary refs log tree commit diff
path: root/compiler/rustc_codegen_gcc
diff options
context:
space:
mode:
authorDylan DPC <99973273+Dylan-DPC@users.noreply.github.com>2022-10-12 22:13:25 +0530
committerGitHub <noreply@github.com>2022-10-12 22:13:25 +0530
commitc763ebc72f45c0d086875f6acf88b48d7f39eb23 (patch)
tree9c1564eac5dd4372ffe3e995409060bc667f907f /compiler/rustc_codegen_gcc
parent40deecef0370dec461279e10d5e8b2f4f57d4900 (diff)
parentbef8681a1837790f2745c1f6a7f8214af2fd7f5d (diff)
downloadrust-c763ebc72f45c0d086875f6acf88b48d7f39eb23.tar.gz
rust-c763ebc72f45c0d086875f6acf88b48d7f39eb23.zip
Rollup merge of #102830 - compiler-errors:constness-parity, 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).
Diffstat (limited to 'compiler/rustc_codegen_gcc')
0 files changed, 0 insertions, 0 deletions