Remove `box_free` lang item
This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
Add `<meta charset="utf-8">` to `-Zdump-mir-spanview` output
Without an explicit `<meta charset>` declaration, some browsers (e.g. Safari) won't detect the page encoding as UTF-8, causing unicode characters in the dump output to display incorrectly.
Add `AliasKind::Weak` for type aliases.
`type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a
```rust
trait Identity {
type Identity;
}
impl<T: Debug> Identity for T {
type Identity = T;
}
<NotDebug as Identity>::Identity
```
type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer.
Similarly:
* a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes
* rustdoc expands the type alias, even though often times users use them for documentation purposes
* diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about.
For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident.
To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition.
Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds.
As a side effect, easily allows fixing https://github.com/rust-lang/rust/issues/108617, which I did.
fixes https://github.com/rust-lang/rust/issues/108617
Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`
We just use an if-let to match on an optional clause at all the places where we transition from `Predicate` -> `Clause`, but I assume that when things like item-bounds and param-env start to only store `Clause`s then those can just be trivially dropped.
r? ``@lcnr``
`#[lang_item]` for `core::ptr::Unique`
Tree Borrows is about to introduce experimental special handling of `core::ptr::Unique` in Miri to give it a semantics.
As of now there does not seem to be a clean way (i.e. other than `&format!("{adt:?}") == "std::ptr::Unique"`) to check if an `AdtDef` represents a `Unique`.
r? `@RalfJung`
Draft: making a lang item
Ignore the always part of #[inline(always)] in MIR inlining
`#[inline(always)]` is used in two cases: for functions that are so trivial it is always profitable to inline them, but also for functions which LLVM thinks are a bad inlining candidate, but which actually turn out to be profitable to inline. That second justification doesn't apply to the MIR inliner, so ignoring our cost estimation for these functions is not necessarily the right right thing to do.
This is basically a wash on non-check runs and a perf benefit in check runs. There are some notable regressions, and I think we might be able to claw those back by turning `#[inline(always)]` into a stronger hint. But I think this PR stands decently on its own as a tidy simplification.
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```
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
