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.
Specialize `Vec::clone_from` for `Copy` types
This should improve performance and reduce code size.
This also improves `clone_from` for `String`, `OsString` and `PathBuf`.
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`
Move some UI tests to more suitable subdirs
The classifui result: https://gist.github.com/JohnTitor/c9e00840990b5e4a8fc562ec3571e427/e06c42226c6038da91e403c33b9947843420cf44
Some notes:
- backtrace-debuginfo.rs: previously I skipped this, I'm still not sure what the best dir is. Any ideas?
- estr-subtyping.rs: Seems a quite old test so removed, shouldn't?
- deref-suggestion.rs: moved to inference as `suggestions` is not an ideal dir.
- issue-43023.rs: a bit misclassified, moved to `derives`
cc #73494
r? `@petrochenkov`
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.
Fix `command-create-pidfd` test inside unprivileged Docker containers
In `src/test/ui/command/command-create-pidfd.rs` (added #81825), the detection code to skip the test on unsupported platforms doesn't account for unprivileged Docker containers (CI uses privileged containers), which leads to a test failure as you can't call the `clone3` syscall in that environment. This PR enhances the detection code to also consider unprivileged containers.
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
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
