| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
When encountering a fn call that has a path to another fn being passed
in, where an `Fn` impl is expected, and the arguments differ, suggest
wrapping the argument with a closure with the appropriate arguments.
|
|
|
|
|
|
|
|
|
|
|
|
Use the same approach used for match arm patterns.
|
|
When encountering match arm (pat if expr) => {}, recover and suggest removing parentheses. Fix #100825.
|
|
|
|
|
|
|
|
likely to appear in for head or match arm
|
|
|
|
When trying to create an inaccessible ADT due to private fields, handle
the case when no fields were passed.
```
error: cannot construct `Foo` with struct literal syntax due to private fields
--> $DIR/issue-76077.rs:8:5
|
LL | foo::Foo {};
| ^^^^^^^^
|
= note: private field `you_cant_use_this_field` that was not provided
```
|
|
This way, most of the parsing code doesn't need to be designed to handle
it, since they should always be treated exactly the same anyhow.
|
|
This is already covered by the normal unexpected char path.
|
|
This restriction made sense back when spaces separated function
parameters, but now that they separate path components, there's
no real ambiguity any more.
Additionally, the Rust language allows it.
|
|
|
|
ConstProp: Correctly remove const if unknown value assigned to it.
Closes #118328
The problematic sequence of MIR is:
```rust
_1 = const 0_usize;
_1 = const _; // This is an associated constant we can't know before monomorphization.
_0 = _1;
```
1. When `ConstProp::visit_assign` happens on `_1 = const 0_usize;`, it records that `0x0usize` is the value for `_1`.
2. Next `visit_assign` happens on `_1 = const _;`. Because the rvalue `.has_param()`, it can't be const evaled.
3. Finaly, `visit_assign` happens on `_0 = _1;`. Here it would think the value of `_1` was `0x0usize` from step 1.
The solution is to remove consts when checking the RValue fails, as they may have contained values that should now be invalidated, as that local was overwritten.
This should probably be back-ported to beta. Stable is more iffy, as it's gone unidentified since 1.70, so I only think it's worthwhile if there's another reason for a 1.74.1 release anyway.
|
|
Print list of missing target features when calling a function with target features outside an unsafe block
Fixes https://github.com/rust-lang/rust/issues/108680
Supersedes https://github.com/rust-lang/rust/pull/109710. I used the same wording for the messages, but the implementation is different.
r? `@est31`
|
|
Suggest `let` or `==` on typo'd let-chain
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 {}
| +
```
|
|
Add `never_patterns` feature gate
This PR adds the feature gate and most basic parsing for the experimental `never_patterns` feature. See the tracking issue (https://github.com/rust-lang/rust/issues/118155) for details on the experiment.
`@scottmcm` has agreed to be my lang-team liaison for this experiment.
|
|
Rollup of 7 pull requests
Successful merges:
- #116839 (Implement thread parking for xous)
- #118265 (remove the memcpy-on-equal-ptrs assumption)
- #118269 (Unify `TraitRefs` and `PolyTraitRefs` in `ValuePairs`)
- #118394 (Remove HIR opkinds)
- #118398 (Add proper cfgs in std)
- #118419 (Eagerly return `ExprKind::Err` on `yield`/`await` in wrong coroutine context)
- #118422 (Fix coroutine validation for mixed panic strategy)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix a typo in a `format_args!` note
|
|
r=compiler-errors
Fix the issue of suggesting unwrap/expect for shorthand field
Fixes #118145
|
|
Dont suggest `!` for path in function call if it has generic args
Fixes #118335
|
|
Fix coroutine validation for mixed panic strategy
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.
Fixes #116953.
|
|
Eagerly return `ExprKind::Err` on `yield`/`await` in wrong coroutine context
This PR does 2 things:
1. Refuses to lower `.await` or `yield` when we are outside of the right coroutine context for the operator. Instead, we lower to `hir::ExprKind::Err`, to silence subsequent redundant errors.
2. Reworks a bit of the span tracking in `LoweringContext` to fix a bad span when we have something like `let x = [0; async_fn().await]` where the `await` is inside of an anon const. The span for the "item" still kinda sucks, since it overlaps with the `await` span, but at least it's accurate.
|
|
|
|
|
|
add track_caller for arith ops
Fixes #114814
`#[track_caller]` is works, r? `@scottmcm`
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #118193 (Add missing period in `std::process::Command` docs)
- #118222 (unify read_to_end and io::copy impls for reading into a Vec)
- #118323 (give dev-friendly error message for incorrect config profiles)
- #118378 (Perform LTO optimisations with wasm-ld + -Clinker-plugin-lto)
- #118399 (Clean dead codes in miri)
- #118410 (update test for new LLVM 18 codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
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.
|
|
with target features outside an unsafe block
|
|
|
|
|
|
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 {}
| +
```
|
|
|
|
|
|
update test for new LLVM 18 codegen
LLVM at HEAD now emits `or disjoint`: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24076#018c1596-8153-488e-b622-951266a02f6c/741-774
|
|
|
|
|
|
LLVM at HEAD now emits `or disjoint`: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24076#018c1596-8153-488e-b622-951266a02f6c/741-774
|
