Do not consider match/let/ref of place that evaluates to `!` to diverge, disallow coercions from them too
Fixes#117288.
This PR implements a heuristic which disables two things that are currently being performed on the HIR when we have **expressions that involve place-like expressions that point to `!`**. Specifically, it will (in certain cases explained below):
### (1.) Disable the `NeverToAny` coercion we implicitly insert for `!`.
Which fixes this inadvertent, sneaky unsoundness:
```
unsafe {
let x: *const ! = &0 as *const u8 as *const !;
let _: () = *x;
}
```
which is UB because currently rust emits an *implicit* NeverToAny coercion even though we really shouldn't be, since there's no read of the value pointed by `x`.
### (2.) Disable the logic which considers expression which evaluate to `!` to diverge, which affects the type returned by the containing block.
Which fixes this unsoundness:
```
fn make_up_a_value<T>() -> T {
unsafe {
let x: *const ! = &0 as *const u8 as *const !;
let _ = *x;
}
}
```
We disable these two operations **if** the expression is a place-like expression (locals, statics, field projections, index operations, and deref operations), and if the parent expression is either:
(1.) the LHS of an assignment
(2.) AddrOf
(3.) A match or let **unless** all of the *patterns consitute a read*, which is explained below:
And finally, a pattern currently is considered to constitute a read **unless** it is a wildcard, or an OR pattern. An OR pattern is considered to constitute a read if all of its subpatterns constitute a read, to remain as conservative as possible in cases like `_ | subpat` or `subpat | _`.
All other patterns are considered currently to constitute a read. Specifically, because `NeverToAny` is a coercion performed on a *value* and not a *place*, `Struct { .. }` on a `!` type must be a coercion currently, and we currently rely on this behavior to allow us to perform coercions like `let _: i32 = x;` where `x: !`.
This is already considered UB by [miri](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=daf3a2246433fe43fdc07d1389c276c9), but also means it does not affect the preexisting UB in this case:
```
let Struct { .. } = *never_ptr;
```
Even though it's likely up for debate since we're not actually reading any data out of the struct, it almost certainly causes inference changes which I do *NOT* want to fix in this PR.
bootstrap: Consolidate editor setup into ./x setup editor & add support for vim, emacs & helix
Add support for automatically setting up the recommended
LSP config for Vim (coc-nvim), Emacs (eglot) and Helix.
Additionally, refactor setup.rs to make it easier to add support
for more editors in the future.
As suggested,
r? `@jieyouxu`
Added rust-analyzer instructions for Helix
That pull request adds information on how to configure Helix to use `rust-analyzer`, and moves the existing configuration to the `src/etc` directory as it's in the `rust` repository. Not adding instructions for other IDE because there's a link leading to the how-to for `rustc`.
bootstrap: add std_features to config.example
fix: use BTreeSet for std-features; add unit tests
* fix formatting of string in front of std_features
* rename `std_features` to `std-features` in config.toml
fix: remove space before std-features in config.toml
fix: remove explicit .into_iter conversion
bootstrap: add details for rust.std-features in config.example.toml
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
fix: remove `Option<T>` from `rust_std_features`
fix: move default rust_std_features to config
fix: make std_features CI rustc incompatible
```
error: expected a pattern, found an expression
--> f889.rs:3:13
|
3 | let (x, y.drop()) = (1, 2); //~ ERROR
| ^^^^^^^^ not a pattern
|
= note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
error[E0532]: expected a pattern, found a function call
--> f889.rs:2:13
|
2 | let (x, drop(y)) = (1, 2); //~ ERROR
| ^^^^ not a tuple struct or tuple variant
|
= note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```
Fix#97200.
Implement lint for regex::Regex compilation inside a loop
Closes#598.
Seems like a pretty simple one, I'm not sure if I sorted out all the lint plumbing correctly because I was adding it to the existing regex pass, but seems to work. The name is a bit jank and I'm super open to suggestions for changing it.
changelog: [`regex_creation_in_loops`]: Added lint for Regex compilation inside loops.
make Cell unstably const
Now that we can do interior mutability in `const`, most of the Cell API can be `const fn`. :) The main exception is `set`, because it drops the old value. So from const context one has to use `replace`, which delegates the responsibility for dropping to the caller.
Tracking issue: https://github.com/rust-lang/rust/issues/131283
`as_array_of_cells` is itself still unstable to I added the const-ness to the feature gate for that function and not to `const_cell`, Cc #88248.
r? libs-api
Handle `rustc_interface` cases of `rustc::potential_query_instability` lint
This PR removes `#![allow(rustc::potential_query_instability)]` occurrences from [`compiler/rustc_interface/`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_interface/) <s>and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors</s> (was not necessary for this PR).
A somewhat tracking issue: https://github.com/rust-lang/rust/issues/84447
r? `@compiler-errors`
Initial support for riscv32{e|em|emc}_unknown_none_elf
We have a research prototype of an RV32EMC target and have been successfully running the e, em, emc programs on it. I'm hoping upstreaming this configuration would make the target maintenance slightly easier.
Configuration is based on the respective {i, im, imc} variants. As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE wrt. RVI is to reduce the number of integer registers to 16 (x0-x15), which also implies
- 2 callee saved registers instead of 12
- 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes
My initial presumption is that this will not impact how the target is defined for the compiler but only becomes relevant at the runtime level. I am willing to investigate, though.
EDIT: LLVM is now told about the presumed 32-bit stack alignment.
`@Disasm` `@romancardenas`
avoid pthread_attr_t in tests
We don't support `pthread_attr_init` so the code here is actually technically wrong (passing attributes to `pthread_create` that were not initialized properly). It's also unnecessary, we can just pass a null pointer for the attributes to indicate "default attributes please".
