Lint against named asm labels
This adds a deny-by-default lint to prevent the use of named labels in inline `asm!`. Without a solution to #81088 about whether the compiler should rewrite named labels or a special syntax for labels, a lint against them should prevent users from writing assembly that could break for internal compiler reasons, such as inlining or anything else that could change the number of actual inline assembly blocks emitted.
This does **not** resolve the issue with rewriting labels, that still needs a decision if the compiler should do any more work to try to make them work.
Try filtering out non-const impls when we expect const impls
**TL;DR**: Associated types on const impls are now bounded; we now disallow calling a const function with bounds when the specified type param only has a non-const impl.
r? `@oli-obk`
Name the captured upvars for closures/generators in debuginfo
Previously, debuggers print closures as something like
```
y::main::closure-0 (0x7fffffffdd34)
```
The pointer actually references to an upvar. It is not very obvious, especially for beginners.
It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like
```
y::main::closure-0 {_captured_ref__b: 0x[...]}
```
r? `@tmandry`
Discussed at https://github.com/rust-lang/rust/pull/84752#issuecomment-831639489 .
Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable
Previously these fails to link with ``undefined reference to `foo'``:
<details>
<summary>Example 1</summary>
```rs
struct AssocFn;
impl AssocFn {
#[no_mangle]
fn foo() {}
}
fn main() {
extern "Rust" {
fn foo();
}
unsafe { foo() }
}
```
([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f1244afcdd26e2a28445f6e82ca46b50))
</details>
<details>
<summary>Example 2</summary>
```rs
#![crate_name = "lib"]
#![crate_type = "lib"]
struct AssocFn;
impl AssocFn {
#[no_mangle]
fn foo() {}
}
```
```rs
extern crate lib;
fn main() {
extern "Rust" {
fn foo();
}
unsafe { foo() }
}
```
</details>
But I believe they should link successfully, because this works:
<details>
```rs
#[no_mangle]
fn foo() {}
fn main() {
extern "Rust" {
fn foo();
}
unsafe { foo() }
}
```
([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=789b3f283ee6126f53939429103ed98d))
</details>
This PR fixes the problem, by adding associated functions that have "custom linkage" to `reachable_set`, just like normal functions.
I haven't tested whether #76211 and [Miri](https://github.com/rust-lang/miri/issues/1837) are fixed by this PR yet, but I'm submitting this anyway since this fixes the examples above.
I added a `run-pass` test that combines my two examples above, but I'm not sure if that's the right way to test this. Maybe I should add / modify an existing codegen test (`src/test/codegen/export-no-mangle.rs`?) instead?
Revert "Rollup merge of #87779 - Aaron1011:stmt-ast-id, r=petrochenkov"
Fixes#87877
This change interacts badly with `noop_flat_map_stmt`,
which synthesizes multiple statements with the same `NodeId`.
I'm working on a better fix that will still allow us to
remove this special case. For now, let's revert the change
to fix the ICE.
This reverts commit a4262cc984, reversing
changes made to 8ee962f88e.
Avoid ICE caused by suggestion
When suggesting dereferencing something that can be iterable in a `for`
loop, erase lifetimes and use a fresh `ty::ParamEnv` to avoid 'region
constraints already solved' panic.
Fix#87657, fix#87709, fix#87651.
Fix closure migration suggestion when the body is a macro.
Fixes https://github.com/rust-lang/rust/issues/87955
Before:
```
warning: changes to closure capture in Rust 2021 will affect drop order
--> src/main.rs:5:13
|
5 | let _ = || panic!(a.0);
| ^^^^^^^^^^---^
| |
| in Rust 2018, closure captures all of `a`, but in Rust 2021, it only captures `a.0`
6 | }
| - in Rust 2018, `a` would be dropped here, but in Rust 2021, only `a.0` would be dropped here alongside the closure
|
help: add a dummy let to cause `a` to be fully captured
|
20~ ($msg:expr $(,)?) => ({ let _ = &a;
21+ $crate::rt::begin_panic($msg)
22~ }),
|
```
After:
```
warning: changes to closure capture in Rust 2021 will affect drop order
--> src/main.rs:5:13
|
5 | let _ = || panic!(a.0);
| ^^^^^^^^^^---^
| |
| in Rust 2018, closure captures all of `a`, but in Rust 2021, it only captures `a.0`
6 | }
| - in Rust 2018, `a` would be dropped here, but in Rust 2021, only `a.0` would be dropped here alongside the closure
|
help: add a dummy let to cause `a` to be fully captured
|
5 | let _ = || { let _ = &a; panic!(a.0) };
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Implement `black_box` using intrinsic
Introduce `black_box` intrinsic, as suggested in https://github.com/rust-lang/rust/pull/87590#discussion_r680468700.
This is still codegenned as empty inline assembly for LLVM. For MIR interpretation and cranelift it's treated as identity.
cc `@Amanieu` as this is related to inline assembly
cc `@bjorn3` for rustc_codegen_cranelift changes
cc `@RalfJung` as this affects MIRI
r? `@nagisa` I suppose
When an incremental fingerprint mismatch occurs, we debug-print
our `DepNode` and query result. Unfortunately, the debug printing
process may cause us to run additional queries, which can result
in a re-entrant fingerprint mismatch error.
To avoid a double panic, this commit adds a thread-local variable
to detect re-entrant calls.
Silence non_fmt_panic from external macros.
This stops the non_fmt_panic lint from triggering if a macro from another crate is entirely responsible. In those cases there's nothing that the current crate can/should do.
See also https://github.com/rust-lang/rust/issues/87621#issuecomment-890311054
Improve formatting of closure capture migration suggestion for multi-line closures.
Fixes https://github.com/rust-lang/rust/issues/87952
Before:
```
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || { let _ = &a;
6 + dbg!(a.0);
7 ~ };
|
```
After:
```
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
7 + dbg!(a.0);
8 ~ };
|
```
Add c_enum_min_bits target spec field, use for arm-none and thumb-none targets
Fixes https://github.com/rust-lang/rust/issues/87917
<s>Haven't tested this yet, still playing around.</s>
This seems to fix the issue.
Implement `black_box` using intrinsic
Introduce `black_box` intrinsic, as suggested in https://github.com/rust-lang/rust/pull/87590#discussion_r680468700.
This is still codegenned as empty inline assembly for LLVM. For MIR interpretation and cranelift it's treated as identity.
cc `@Amanieu` as this is related to inline assembly
cc `@bjorn3` for rustc_codegen_cranelift changes
cc `@RalfJung` as this affects MIRI
r? `@nagisa` I suppose
