If the TargetMachine is disposed after the Context is disposed, it can
lead to use after frees in some cases.
I've observed this happening occasionally on code compiled for
aarch64-pc-windows-msvc using `-Zstack-protector=strong` but other users
have reported AVs from host aarch64-pc-windows-msvc compilers as well.
Pass +forced-atomics feature for riscv32{i,im,imc}-unknown-none-elf
As said in https://github.com/rust-lang/rust/pull/98333#issuecomment-1666375293, `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd
~~This PR is currently marked as a draft because:~~
- ~~`forced-atomics` target feature is currently broken (https://github.com/rust-lang/rust/issues/114153).~~ EDIT: Fixed
- ~~`forced-atomics` target feature has been added in LLVM 16 (f5ed0cb217), but the current minimum LLVM version [is 15](90f0b24ad3/src/bootstrap/llvm.rs (L557)). In LLVM 15, the atomic load/store of these targets generates libcalls anyway.~~ EDIT: LLVM 15 has been dropped
Depending on the policy on the minimum LLVM version for these targets, this may be blocked until the minimum LLVM version is increased to 16.
r? `@Amanieu`
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.
Fix#11893
Trigerring on expressions returning `()` uses the arguments of the
`map_or_else()` rewrite only for their side effects. This does lead
to code which is harder to read than the original.
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 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.
utilize stdlib debug assertion status in compiletest
Implemented a new flag `--with-debug-assertions` on compiletest to pass the stdlib debug assertion status from bootstrap.
Resolves#115171
Use `usize::repeat_u8` instead of implementing `repeat_byte` in `memchr.rs`
It's simpler that way and the tricks don't actually make a difference: https://godbolt.org/z/zrvYY1dGx
[`redundant_guards`]: catch `is_empty`, `starts_with` and `ends_with` on slices and `str`s
Fixes#11807
Few things worth mentioning:
- Taking `snippet`s is now done at callsite, instead of passing a span and doing it in `emit_redundant_guards`. This is because we now need custom suggestion strings in certain places, like `""` for `str::is_empty`.
- This now uses `snippet` instead of `snippet_with_applicability`. I don't think this really makes any difference for `MaybeIncorrect`, though?
- This could also lint byte strings, as they're of type `&[u8; N]`, but that can be ugly so I decided to leave it out for now
changelog: [`redundant_guards`]: catch `str::is_empty`, `slice::is_empty`, `slice::starts_with` and `slice::ends_with`
Rollup of 7 pull requests
Successful merges:
- #118157 (Add `never_patterns` feature gate)
- #118191 (Suggest `let` or `==` on typo'd let-chain)
- #118231 (also add is_empty to const raw slices)
- #118333 (Print list of missing target features when calling a function with target features outside an unsafe block)
- #118426 (ConstProp: Correctly remove const if unknown value assigned to it.)
- #118428 (rustdoc: Move `AssocItemRender` and `RenderMode` to `html::render`.)
- #118438 (Update nto-qnx.md)
Failed merges:
- #118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)
r? `@ghost`
`@rustbot` modify labels: rollup
Update nto-qnx.md
x.py does not support specifying multiple `--target` keywords. The targets must be specified comma separated.
Error:
`error: the argument '--target <TARGET>' cannot be used multiple times`
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.
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.
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:
- #118342 (Dont suggest `!` for path in function call if it has generic args)
- #118383 (Address unused tuple struct fields in the standard library)
- #118401 (`rustc_ast_lowering` cleanups)
- #118409 (format_foreign.rs: unwrap return Option value for `fn position`, as it always returns Some)
- #118413 (Fix the issue of suggesting unwrap/expect for shorthand field)
- #118425 (Update cargo)
- #118429 (Fix a typo in a `format_args!` note)
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
7 commits in 9b13310ca596020a737aaa47daa4ed9ff8898a2f..26333c732095d207aa05932ce863d850fb309386
2023-11-24 16:20:51 +0000 to 2023-11-28 20:07:39 +0000
- docs: link to the packages lint table from the related workspace table (rust-lang/cargo#13057)
- Add more doc comments for gc changes. (rust-lang/cargo#13055)
- docs: Provide pointers for MSRV (rust-lang/cargo#13056)
- Fixed typo in SemVer Compatibility documentation page (rust-lang/cargo#13054)
- refactor: use custom error instead of anyhow (rust-lang/cargo#13050)
- review and remove ignored tests in rustfix (rust-lang/cargo#13047)
- docs: add doc comments for rustfix (rust-lang/cargo#13048)
r? ghost
format_foreign.rs: unwrap return Option value for `fn position`, as it always returns Some
Trivial cleanup.
It will be nice to have way to run exhaustiveness analysis on similar cases to see dead code.
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.
