Fix misleading "impl Trait" error
The kinds can't be compared directly, as types with references are treated as different because the lifetimes aren't bound in ty, but are in expected.
Closes#84160
Add support for leaf function frame pointer elimination
This PR adds ability for the target specifications to specify frame
pointer emission type that's not just “always” or “whatever cg decides”.
In particular there's a new mode that allows omission of the frame
pointer for leaf functions (those that don't call any other functions).
We then set this new mode for Aarch64-based Apple targets.
Fixes#86196
rustc_span: Explicitly handle crates that differ from package names
The sha-1 and md-5 packages contain crates named sha1 and md5,
respectively. This discrepancy makes it somewhat more challenging to
automate detection of unused crates. Explicitly rename the packages to
the names of the crates they contain, to simplify such detection.
Add suggestions for "undefined reference" link errors
This adds a suggestion for "undefined reference to ..." linking errors to install or specify the location to an external library. Since there is no defined error format for linkers, we just check if there was a failure and if that failure contains the string `undefined reference to`. This also makes it impossible to test this, since the output depends on the system linker. The output now looks like:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64" "linking_failure.linking_failure.7rcbfp3g-cgu.0.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.1.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.2.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.3.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.4.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.5.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.6.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.7.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.8.rcgu.o" "linking_failure.53u64zklswtfazes.rcgu.o" "-Wl,--as-needed" "-L" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-01ce3ba5c629d02f.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-f1f2102409186354.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-1e8b6b56a999f838.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-d0e93eb4e14f1d19.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1d7e39d75d082b43.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-ade42e945045b261.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-1a65064fccf4ebc1.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-4d699c310fdfe72d.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-1cafa68a696ec800.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-e9f1c8c4dab2f046.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-ecc1a743be25c7f7.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-e074031c4b66b6b6.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-9aa6ed9f1d3bfd53.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-7862bf96c2250ca0.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f02ce0dc7895b5fd.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-3af9c60917570521.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ca16fc7bb3645684.rlib" "-Wl,--end-group" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-d8e1a5b7299604cc.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "linking_failure" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs"
= note: /usr/bin/ld: linking_failure.linking_failure.7rcbfp3g-cgu.3.rcgu.o: in function `linking_failure::main':
linking_failure.7rcbfp3g-cgu.3:(.text._ZN15linking_failure4main17h52b6e3052e444479E+0x3): undefined reference to `doesnt_exist_thiwthwfyl'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
= help: some `extern` functions couldn't be found; you may need to install or specify the path to some dependencies
= note: use the -L flag to specify the library lookup path
= note: use the cargo:rustc-link-search directive to specify the library lookup path with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-search)
error: aborting due to previous error
```
Fix ICE when `main` is declared in an `extern` block
Changes in #84401 to implement `imported_main` changed how the crate entry point is found, and a declared `main` in an `extern` block was detected erroneously. This was causing the ICE described in #86110.
This PR adds a check for this case and emits an error instead. Previously a `main` declaration in an `extern` block was not detected as an entry point at all, so emitting an error shouldn't break anything that worked previously. In 1.52.1 stable this is demonstrated, with a `` `main` function not found`` error.
Fixes#86110
Remove unused dependencies from compiler crates
Various compiler crates have dependencies that they don't appear to use. I used some scripting to detect such dependencies, filtered them based on some manual review, and removed those that do indeed appear to be entirely unused.
Test cross-crate usage of `feature(const_trait_impl)`
This PR does two things:
- Fixes metadata not encoded properly for functions in const trait impls.
- Adds tests for using const trait impls cross-crate with the feature gate on the user crate either enabled or disabled.
AFAIK, this means we can now constify some trait impls in the standard library 🎉
See #67792 for the tracking issue, cc `@oli-obk`
Check node kind to avoid ICE in `check_expr_return()`
This PR fixes#86721. The ICE described there is apparently due to a misunderstanding:
e98897e5dc/compiler/rustc_typeck/src/check/expr.rs (L684-L685)
Intuitively, one would think that calling `expect_item()` after `get_parent_item()` should succeed, but as it turns out, `get_parent_item()` can also return foreign, trait, and impl items as well as crates, whereas `expect_item()` specifically expects a `Node::Item`. I have therefore added an extra check to prevent this ICE.
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types).
Instead, each debug symbol name should be unique and useful:
* Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.
* Qualify the principal trait for dynamic types.
* If there is no principal trait for a dynamic type, emit all other traits instead.
* Respect the `qualified` argument when emitting ref and pointer types.
* For implementations, emit the disambiguator.
* Print const generics when emitting generic parameters or arguments.
Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
* Avoid characters with special meaning (`#`, `[`, `"`, `+`).
* Never start a name with `<` or `{` as this is treated as an operator.
* `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).
* Emit function declarations using C/C++ style syntax (e.g., leading return type).
* Emit arrays as a synthetic `array$<type, size>` type.
* Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
This PR adds ability for the target specifications to specify frame
pointer emission type that's not just “always” or “whatever cg decides”.
In particular there's a new mode that allows omission of the frame
pointer for leaf functions (those that don't call any other functions).
We then set this new mode for Aarch64-based Apple targets.
Fixes#86196
Introduce -Zprofile-closures to evaluate the impact of 2229
This creates a CSV with name "closure_profile_XXXXX.csv", where the
variable part is the process id of the compiler.
To profile a cargo project you can run one of the following depending on
if you're compiling a library or a binary:
```
cargo +nightly rustc --lib -- -Zprofile-closures
cargo +nightly rustc --bin {binary_name} -- -Zprofile-closures
```
r? `@nikomatsakis`
Only include lint in future_incompatible lint group if not an edition lint
A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition.
We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though.
r? `@nikomatsakis`
