Validation introduced in #113124 allows UnwindAction::Continue and
TerminatorKind::Resume to occur only in functions with ABI that can
unwind. The function ABI depends on the panic strategy, which can vary
across crates.
Usually MIR is built and validated in the same crate. The coroutine drop
glue thus far was an exception. As a result validation could fail when
mixing different panic strategies.
Avoid the problem by executing AbortUnwindingCalls along with the
validation.
When encountering a bare assignment in a let-chain, suggest turning the
assignment into a `let` expression or an equality check.
```
error: expected expression, found `let` statement
--> $DIR/bad-if-let-suggestion.rs:5:8
|
LL | if let x = 1 && i = 2 {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
help: you might have meant to continue the let-chain
|
LL | if let x = 1 && let i = 2 {}
| +++
help: you might have meant to compare for equality
|
LL | if let x = 1 && i == 2 {}
| +
```
Perform LTO optimisations with wasm-ld + -Clinker-plugin-lto
Fixes (partially) #60059. Technically, `--target wasm32-unknown-unknown -Clinker-plugin-lto` would complete without errors before, but it was not producing optimized code. At least, it may have been but it was probably not the opt-level people intended.
Similarly to #118377, this could benefit from a warning about using an explicit libLTO path with LLD, which will ignore it and use its internal LLVM. Especially given we always use lld on wasm targets. I left the code open to that possibility rather than making it perfectly neat.
effects: Run `enforce_context_effects` for all method calls
So that we also perform checks when overloaded `PartialEq`s are called.
r? `@compiler-errors`
They're identical to the same-named types from `ast`. I find it silly
(and inefficient) to have all this boilerplate code to convert one type
to an identical type.
There is already a small amount of type sharing between the AST and HIR,
e.g. `Attribute`, `MacroDef`.
The commit adds a `pub use` to `rustc_hir` so that, for example,
`ast::BinOp` can also be referred to as `hir::BinOp`. This is so the
many existing `hir`-qualified mentions of these types don't need to
change.
The commit also moves a couple of operations from the (removed) HIR
types to the AST types, e.g. `is_by_value`.
rustc_span: Use correct edit distance start length for suggestions
Otherwise the suggestions can be off-base for non-ASCII identifiers. For example suggesting that `Ok` is a name similar to `读文`.
Closes https://github.com/rust-lang/rust/issues/72553.
QueryContext: rename try_collect_active_jobs -> collect_active_jobs, change return type from Option<QueryMap> to QueryMap
As there currently always Some(...) inside.
Added linker_arg(s) Linker trait methods for link-arg to be prefixed "-Wl," for cc-like linker args and not verbatim
https://github.com/rust-lang/rust/issues/99427#issuecomment-1234443468
> here's one possible improvement to -l link-arg making it more portable between linkers and useful - befriending it with the verbatim modifier (https://github.com/rust-lang/rust/issues/99425).
>
> -l link-arg:-verbatim=-foo would add -Wl,-foo (or equivalent) when C compiler is used as a linker, and just -foo when bare linker is used.
> -l link-arg:+verbatim=-bar on the other hand would always pass just -bar.
Add `pretty_terminator` to pretty stable-mir
~Because we don't have successors in `stable_mir` this is somewhat lacking but it's better than nothing~, also fixed bug(?) with `Opaque` which printed extra `"` when we try to print opaqued `String`.
**Edit**: Added successors so this covers Terminators as a whole.
r? `@celinval`
Account for `!` arm in tail `match` expr
On functions with a default return type that influences the coerced type of `match` arms, check if the failing arm is actually of type `!`. If so, suggest changing the return type so the coercion against the prior arms is successful.
```
error[E0308]: `match` arms have incompatible types
--> $DIR/match-tail-expr-never-type-error.rs:9:13
|
LL | fn bar(a: bool) {
| - help: try adding a return type: `-> i32`
LL | / match a {
LL | | true => 1,
| | - this is found to be of type `{integer}`
LL | | false => {
LL | | never()
| | ^^^^^^^
| | |
| | expected integer, found `()`
| | this expression is of type `!`, but it get's coerced to `()` due to its surrounding expression
LL | | }
LL | | }
| |_____- `match` arms have incompatible types
```
Fix#24157.
- Rename them both `as_str`, which is the typical name for a function
that returns a `&str`. (`to_string` is appropriate for functions
returning `String` or maybe `Cow<'a, str>`.)
- Change `UnOp::as_str` from an associated function (weird!) to a
method.
- Avoid needless `self` dereferences.
Do not erase late bound regions when selecting inherent associated types
In the fix for #97156 we would want the following code:
```rust
#![feature(inherent_associated_types)]
#![allow(incomplete_features)]
struct Foo<T>(T);
impl Foo<fn(&'static ())> {
type Assoc = u32;
}
trait Other {}
impl Other for u32 {}
// FIXME(inherent_associated_types): Avoid emitting two diagnostics (they only differ in span).
// FIXME(inherent_associated_types): Enhancement: Spruce up the diagnostic by saying something like
// "implementation is not general enough" as is done for traits via
// `try_report_trait_placeholder_mismatch`.
fn bar(_: Foo<for<'a> fn(&'a ())>::Assoc) {}
//~^ ERROR mismatched types
//~| ERROR mismatched types
fn main() {}
```
to fail with ...
```
error[E0220]: associated type `Assoc` not found for `Foo<for<'a> fn(&'a ())>` in the current scope
--> tests/ui/associated-inherent-types/issue-109789.rs:18:36
|
4 | struct Foo<T>(T);
| ------------- associated item `Assoc` not found for this struct
...
18 | fn bar(_: Foo<for<'a> fn(&'a ())>::Assoc) {}
| ^^^^^ associated item not found in `Foo<for<'a> fn(&'a ())>`
|
= note: the associated type was found for
- `Foo<fn(&'static ())>`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0220`.
```
This PR fixes the ICE we are currently getting "was a subtype of Foo<Binder(fn(&ReStatic ()), [])> during selection but now it is not"
Also fixes#112631
r? `@lcnr`
On functions with a default return type that influences the coerced type
of `match` arms, check if the failing arm is actually of type `!`. If
so, suggest changing the return type so the coercion against the prior
arms is successful.
```
error[E0308]: `match` arms have incompatible types
--> $DIR/match-tail-expr-never-type-error.rs:9:13
|
LL | fn bar(a: bool) {
| - help: try adding a return type: `-> i32`
LL | / match a {
LL | | true => 1,
| | - this is found to be of type `{integer}`
LL | | false => {
LL | | never()
| | ^^^^^^^
| | |
| | expected integer, found `()`
| | this expression is of type `!`, but it get's coerced to `()` due to its surrounding expression
LL | | }
LL | | }
| |_____- `match` arms have incompatible types
```
Fix#24157.
Suggest swapping the order of `ref` and `box`
It is not valid grammar to write `ref box <ident>` in patterns, but `box ref <ident>` is.
This patch adds a diagnostic to suggest swapping them, analogous to what we do for `mut let`.
