Deeply normalize when computing implied outlives bounds
r? lcnr
Unfortunately resolving regions is still slightly scuffed (though in an unrelated way). Specifically, we should be normalizing our param-env outlives when constructing the `OutlivesEnv`; otherwise, these assumptions (dd2837ec5d/compiler/rustc_infer/src/infer/outlives/env.rs (L78)) are not constructed correctly.
Let me know if you want us to track that somewhere.
Print name of env var in `--print=deployment-target`
The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example.
Behaviour before this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
deployment_target=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
deployment_target=1.0
```
Behaviour after this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
MACOSX_DEPLOYMENT_TARGET=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
XROS_DEPLOYMENT_TARGET=1.0
```
My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this:
- b292ef6934/src/build_context.rs (L1199-L1220)
- daab9244b0/src/lib.rs (L3422-L3426)
`maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](https://github.com/rust-lang/cc-rs/pull/848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](https://github.com/rust-lang/cc-rs/pull/901) [reverted](https://github.com/rust-lang/cc-rs/pull/943) in `v1.0.85`.
So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine.
``@BlackHoleFox`` wdyt?
``@rustbot`` label O-apple
r? compiler
Get rid of HIR const checker
As far as I can tell, the HIR const checker was implemented in https://github.com/rust-lang/rust/pull/66170 because we were not able to issue useful const error messages in the MIR const checker.
This seems to have changed in the last 5 years, probably due to work like #90532. I've tweaked the diagnostics slightly and think the error messages have gotten *better* in fact.
Thus I think the HIR const checker has reached the end of its usefulness, and we can retire it.
cc `@RalfJung`
Change `AttrArgs::Eq` to a struct variant
Cleanups for simplifying https://github.com/rust-lang/rust/pull/131808
Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code
fix ICE when promoted has layout size overflow
Turns out there is no reason to distinguish `tainted_by_errors` and `can_be_spurious` here, we can just track whether we allow this even in "infallible" constants.
Fixes https://github.com/rust-lang/rust/issues/125476
Use c"lit" for CStrings without unwrap
I've reviewed uses of `CString::new("lit")`.
Some could be changed to `c"lit"`. Some could be changed to `c"lit".to_owned()`, avoiding an `unwrap()`.
Many `CString` documentation examples could be simplified. I deliberately haven't changed all the examples to use the exact same expression, so that they can demonstrate many ways of creating `CString`s.
I've left UI tests mostly unchanged, because `c""` requires edition 2021, but most UI tests use 2015, and I didn't want to accidentally change what the tests are testing.
Move `Const::{from_anon_const,try_from_lit}` to hir_ty_lowering
Fixes#128176.
This accomplishes one of the followup items from #131081.
These operations are much more about lowering the HIR than about
`Const`s themselves. They fit better in hir_ty_lowering with
`lower_const_arg` (formerly `Const::from_const_arg`) and the rest.
To accomplish this, `const_evaluatable_predicates_of` had to be changed
to not use `from_anon_const` anymore. Instead of visiting the HIR and
lowering anon consts on the fly, it now visits the `rustc_middle::ty`
data structures instead and directly looks for `UnevaluatedConst`s. This
approach was proposed in:
https://github.com/rust-lang/rust/pull/131081#discussion_r1821189257
r? `@BoxyUwU`
show forbidden_lint_groups in future-compat reports
Part of https://github.com/rust-lang/rust/issues/81670. This has been a future-compat lint for a while, time to dial it up to show up in reports.
These operations are much more about lowering the HIR than about
`Const`s themselves. They fit better in hir_ty_lowering with
`lower_const_arg` (formerly `Const::from_const_arg`) and the rest.
To accomplish this, `const_evaluatable_predicates_of` had to be changed
to not use `from_anon_const` anymore. Instead of visiting the HIR and
lowering anon consts on the fly, it now visits the `rustc_middle::ty`
data structures instead and directly looks for `UnevaluatedConst`s. This
approach was proposed in:
https://github.com/rust-lang/rust/pull/131081#discussion_r1821189257
`impl Default for EarlyDiagCtxt`
for small rustc_driver programs, most of their imports will currently be related to diagnostics. this change simplifies their code so it's more clear what in the driver is modified from the default.
this is especially important for external drivers which are out of tree and not updated in response to breaking changes. for these drivers, each import is a liability for future code, since it can be broken when refactors happen.
here is an example driver which is simplified by these changes:
```diff
diff --git a/src/main.rs b/src/main.rs
index f81aa3e..11e5f18 100644
--- a/src/main.rs
+++ b/src/main.rs
`@@` -1,16 +1,8 `@@`
#![feature(rustc_private)]
extern crate rustc_driver;
extern crate rustc_interface;
-extern crate rustc_errors;
-extern crate rustc_session;
use rustc_driver::Callbacks;
-use rustc_errors::{emitter::HumanReadableErrorType, ColorConfig};
use rustc_interface::interface;
-use rustc_session::config::ErrorOutputType;
-use rustc_session::EarlyDiagCtxt;
struct DisableSafetyChecks;
`@@` -26,11 +18,7 `@@` fn main() {
"https://github.com/jyn514/jyn514.github.io/issues/new",
|_| (),
);
- let handler = EarlyDiagCtxt::new(ErrorOutputType::HumanReadable(
- HumanReadableErrorType::Default,
- ColorConfig::Auto,
- ));
- rustc_driver::init_rustc_env_logger(&handler);
+ rustc_driver::init_rustc_env_logger(&Default::default());
std::process::exit(rustc_driver::catch_with_exit_code(move || {
let args: Vec<String> = std::env::args().collect();
rustc_driver::RunCompiler::new(&args, &mut DisableSafetyChecks).run()
```
remove `Ty::is_copy_modulo_regions`
Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.
I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.
r? `@compiler-errors` cc #132279
Eliminate magic numbers from expression precedence
Context: see https://github.com/rust-lang/rust/pull/133140.
This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.
This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.
- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.
- Squashing the `Closure` and `Jump` cases into a single precedence level.
- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.
FYI `@fmease` — you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.
check local cache even if global is usable
we store overflow errors locally, even if we can otherwise use the global cache for this goal. should fix#133616, didn't test it locally yet as diesel tends to hit an unrelated debug assertion in rustdoc.
r? types
for small rustc_driver programs, most of their imports will currently be related to diagnostics. this change simplifiers their code so it's more clear what in the driver is modified from the default.
this is especially important for external drivers which are out of tree and not updated in response to breaking changes. for these drivers, each import is a liability for future code, since it can be broken when refactors happen.
here is an example driver which is simplified by these changes:
```
diff --git a/src/main.rs b/src/main.rs
index f81aa3e..11e5f18 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -1,16 +1,8 @@
#![feature(rustc_private)]
extern crate rustc_driver;
extern crate rustc_interface;
-extern crate rustc_errors;
-extern crate rustc_session;
use rustc_driver::Callbacks;
-use rustc_errors::{emitter::HumanReadableErrorType, ColorConfig};
use rustc_interface::interface;
-use rustc_session::config::ErrorOutputType;
-use rustc_session::EarlyDiagCtxt;
struct DisableSafetyChecks;
@@ -26,11 +18,7 @@ fn main() {
"https://github.com/jyn514/jyn514.github.io/issues/new",
|_| (),
);
- let handler = EarlyDiagCtxt::new(ErrorOutputType::HumanReadable(
- HumanReadableErrorType::Default,
- ColorConfig::Auto,
- ));
- rustc_driver::init_rustc_env_logger(&handler);
+ rustc_driver::init_rustc_env_logger(&Default::default());
std::process::exit(rustc_driver::catch_with_exit_code(move || {
let args: Vec<String> = std::env::args().collect();
rustc_driver::RunCompiler::new(&args, &mut DisableSafetyChecks).run()
```
The `Borrowed` variant is no longer used. This commit removes it, along
with the `as_results_cursor` method that produces it, and renames
`as_results_cursor_mut` as `as_results_cursor`.
As of #133155 `Formatter:new` uses `as_results_cursor` to create a
non-mutable results reference, and then later that is accessed via
`deref_mut` which results in a runtime abort. Changing to
`as_results_cursor_mut` fixes it.
Fixes#133641.
Remove `hir::ArrayLen`
This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.
r? `@BoxyUwU`
coverage: Use a query to identify which counter/expression IDs are used
Given that we already have a query to identify the highest-numbered counter ID in a MIR body, we can extend that query to also build bitsets of used counter/expression IDs. That lets us avoid some messy coverage bookkeeping during the main MIR traversal for codegen.
This does mean that we fail to treat some IDs as used in certain MIR-inlining scenarios, but I think that's fine, because it means that the results will be consistent across all instantiations of a function.
---
There's some more cleanup I want to do in the function coverage collector, since it isn't really collecting anything any more, but I'll leave that for future work.
