Handle interpolated literal errors
Not sure why it was doing a whole dance to re-match on the token kind when it seems like `Lit::from_token` does the right thing for both macro-arg and regular literals. Nothing seems to have regressed diagnostics-wise from the change, though.
Fixes#112622
r? ``@nnethercote``
Opportunistically resolve regions in new solver
Use `opportunistic_resolve_var` during canonicalization to collapse some regions.
We have to start using `CanonicalVarValues::is_identity_modulo_regions`. We also have to modify that function to consider responses like `['static, ^0, '^1, ^2]` to be an "identity" response, since because we opportunistically resolve regions, there's no longer a 1:1 mapping between canonical var values and bound var indices in the response...
There's one nasty side-effect -- one test (`tests/ui/dyn-star/param-env-infer.rs`) starts to ICE because the certainty goes from `Yes` to `Maybe(Overflow)`... Not exactly sure why, though? Putting this up for discussion/investigation.
r? ```@lcnr```
Instantiate closure synthetic substs in root universe
In the UI test example, we end up generalizing an associated type (something like `<Map<Option<i32>, [closure upvars=?0]> as IntoIterator>::Item` generalizes into `<Map<Option<i32>, [closure upvars=?1]> as IntoIterator>::Item`) then assigning it to itself, emitting an alias-relate goal. This trivially holds via one of the normalizes-to candidates, instead of relating substs, so when closure analysis eventually sets `?0` to the actual upvars, `?1` never gets constrained. This ends up being reported as an ambiguity error during writeback.
Instead, we can take advantage of the fact that we *know* the closure substs live in the root universe. This will prevent them being generalized, since they always can be named, and the alias-relate above never gets emitted at all.
We can probably do this to a handful of other `next_ty_var` calls in typeck for variables that are clearly associated with the body of the program, but I wanted to limit this for now. Eventually, if we end up representing universes more faithfully like a tree or whatever, we can remove this and turn it back to just a call to `next_ty_var`.
Note: This is incredibly order-dependent -- we need to be assigning a type variable that was created *before* the closure substs, and we also need to actually have an unnormalized type at the time of the assignment. This currently seems easiest to trigger during call argument analysis just due to the fact that we instantiate the call's substs, normalize, THEN check args.
r? ```@lcnr```
Add an `ensure_sufficient_stack` to `LateContextAndPass::visit_expr`
This is [apparently](365396801) where it's busting stack in #112238, and the comments for `ensure_sufficient_stack` say that
> E.g. almost any call to visit_expr or equivalent can benefit from this.
So this seems like a reasonable change.
Hopefully it'll keep this from happening in other places too -- https://github.com/rust-lang/rust/pull/111818#issuecomment-1585023914 hit something similar when updating a lint (bors failure is 9377196369), so with any luck this will keep small permutations of things from tripping over the limit.
Rollup of 8 pull requests
Successful merges:
- #112403 (Prevent `.eh_frame` from being emitted for `-C panic=abort`)
- #112517 (`suspicious_double_ref_op`: don't lint on `.borrow()`)
- #112529 (Extend `unused_must_use` to cover block exprs)
- #112614 (tweak suggestion for argument-position `impl ?Sized`)
- #112654 (normalize closure output in equate_inputs_and_outputs)
- #112660 (Migrate GUI colors test to original CSS color format)
- #112664 (Add support for test tmpdir to fuchsia test runner)
- #112669 (Fix comment for ptr alignment checks in codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
Extend `unused_must_use` to cover block exprs
Given code like
```rust
#[must_use]
fn foo() -> i32 {
42
}
fn warns() {
{
foo();
}
}
fn does_not_warn() {
{
foo()
};
}
fn main() {
warns();
does_not_warn();
}
```
### Before This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: 1 warning emitted
```
### After This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: unused return value of `foo` that must be used
--> test.rs:14:9
|
14 | foo()
| ^^^^^
|
help: use `let _ = ...` to ignore the resulting value
|
14 | let _ = foo();
| +++++++ +
warning: 2 warnings emitted
```
Fixes#104253.
Prevent `.eh_frame` from being emitted for `-C panic=abort`
Since `CheckAlignment` pass is after the `AbortUnwindingCalls` pass, the `UnwindAction::Terminate` inserted in it has no chance to be converted to `UnwindAction::Unreachable` anymore, causing us to emit landing pads that are not necessary. Although these landing pads can themselves be eliminated by LLVM, `.eh_frame` sections are still generated. This causes trouble for Rust-for-Linux project recently.
This PR changes it to generate `UnwindAction::Terminate` when we opt for `-Cpanic=unwind`, and `UnwindAction::Unreachable` for `-Cpanic=abort`.
`@ojeda`
Sync rustc_codegen_cranelift
The main highlights this time are a cranelift update, some x86 vendor intrinsic implementations and preparations for testing cg_clif in CI here.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
This is apparently where it's busting stack, and the comments for `ensure_sufficient_stack` say that
> E.g. almost any call to visit_expr or equivalent can benefit from this.
Like for rlibs, the paths on the linker command line need to be relative
paths if the sysroot was specified by the user to be a relative path.
Dylibs put the path in /LIBPATH instead of into the file path of the
library itself, so we rehome the libpath and adjust the rehoming function
to be able to support both use cases, rlibs and dylibs.
Always put the `create_size_estimate` calls and `debug_dump` calls
within a timed scopes. This makes the four main steps look more similar
to each other.
The comment says "Find the smallest CGU that has exported symbols and
put the dead function stubs in that CGU". But the code sorts the CGUs by
size (smallest first) and then searches them in reverse order, which
means it will find the *largest* CGU that has exported symbols.
The erroneous code was introduced in #92142.
This commit changes it to use a simpler search, avoiding the sort, and
fixes the bug in the process.
Fix explicit-outlives-requirements lint span
Fixes#105150 which caused the span reported by the explicit-outlives-requirements lint to be incorrect when
1) the lint should suggest the entire where clause to be removed and
2) there are inline bounds present that are not inferable outlives requirements
In particular, this would cause rustfix to leave a dangling empty where clause.
Error on unconstrained lifetime in RPITIT
Fixes#109468
The only thing is that I had to split `tests/ui/impl-trait/in-trait/method-signature-matches.rs` into a bunch of different revisions because some error aren't being emitted if all the different examples are all together in one file 🤔
r? `@oli-obk` just because i know you'll review it, feel free to re-roll
Properly check associated consts for infer placeholders
We only reported an error if it was in a "suggestable" position (according to `is_suggestable_infer_ty`) -- this isn't correct for infer tys that can show up in other places in the constant's type, like behind a dyn trait.
fixes#112491
Improve docs/clean up negative overlap functions
Clean up some functions in ways that should not affect behavior, change some names to be clearer (`negative_impl` and `implicit_negative` are not really clear imo), and add some documentation examples.
r? `@spastorino`
Introduce a `Stable` trait to translate MIR to SMIR
This PR introduces a trait `Stable` which defines a type `T` and a `stable()` method to convert the current type to its stable MIR version.
This change is just an implementation detail, and I wanted to get some feedback to whether it would be cleaner than having the `rustc_<type>_to_<type>()` methods for every type we translate to SMIR.
r? `@oli-obk`
r? `@spastorino`
Don't print unsupported split-debuginfo modes with `-Zunstable-options`
Currently unsupported `split-debuginfo` options are enabled by `-Zunstable-options`, for projects that have `-Zunstable-options` for other reasons this can be [an unexpected interaction](https://github.com/rust-lang/rust-clippy/pull/10516#issuecomment-1562604764)
This PR makes it so that `--print split-debuginfo -Zunstable-options` doesn't print unsupported modes, so that a cargo config of e.g.
```toml
[profile.dev]
split-debuginfo = "unpacked"
```
Would not cause an unsupported mode to be enabled on `x86_64-pc-windows-msvc`
loongarch64-none*: Remove environment component from llvm target
A warning is reported when the LLVM triple-implied ABI conflicts with the provided target-abi.
```
warning: triple-implied ABI conflicts with provided target-abi ‘lp64s', using target-abi
```
Specifically, the ABI hint comes from the environment component of the triple. When only the target-abi is provided and no environment, there is no conflict. This PR removes the environment component from the LLVM target name of the `loongarch64-unknown-none-softfloat` target.
When the `--sysroot` is specified as relative to the current working
directory, the sysroot's rlibs should also be specified as relative
paths. Otherwise, the current working directory ends up in the
absolute paths, and in the linker command line. And the entire linker
command line appears in the PDB file generated by the MSVC linker.
When adding an rlib to the linker command line, if the rlib's canonical
path is in the sysroot's canonical path, then use the current sysroot
path + filename instead of the full absolute path to the rlib. This
means that when `--sysroot=foo` is specified, the linker command line
will contain `foo/rustlib/target/lib/lib*.rlib` instead of the full
absolute path to the same.
This addresses https://github.com/rust-lang/rust/issues/112586
Collect VTable stats & add `-Zprint-vtable-sizes`
This is a bit hacky/buggy, but I'm not entirely sure how to fix it, so I want to ask reviewers for help...
To try this, use either of those:
- `cargo clean && RUSTFLAGS="-Zprint-vtable-sizes" cargo +toolchain b`
- `cargo clean && cargo rustc +toolchain -Zprint-vtable-sizes`
- `rustc +toolchain -Zprint-vtable-sizes ./file.rs`
Safe Transmute: Enable handling references
This patch enables support for references in Safe Transmute, by generating nested obligations during trait selection. Specifically, when we call `confirm_transmutability_candidate(...)`, we now recursively traverse the `rustc_transmute::Answer` tree and create obligations for all the `Answer` variants, some of which include multiple nested `Answer`s.
