Load only the crate header for `locator::crate_matches`
Previously, we used the following info to determine whether to load the crate:
1. The METADATA_HEADER, which includes a METADATA_VERSION constant
2. The embedded rustc version
3. Various metadata in the `CrateRoot`, including the SVH
This worked ok most of the time. Unfortunately, when building locally the rustc version is always
the same because `omit-git-hash` is on by default. That meant that we depended only on 1 and 3, and
we are not very good about bumping METADATA_VERSION (it's currently at 7) so in practice we were
only depending on 3. `CrateRoot` is a very large struct and changes somewhat regularly, so this led
to a steady stream of crashes from trying to load it.
Change the logic to add an intermediate step between 2 and 3: introduce a new `CrateHeader` struct
that contains only the minimum info needed to decide whether the crate should be loaded or not. That
avoids having to load all of `CrateRoot`, which in practice means we should crash much less often.
Note that this works because the SVH should be different between any two dependencies, even if the
compiler has changed, because we use `-Zbinary-dep-depinfo` in bootstrap. See
https://github.com/rust-lang/rust/pull/111329#issuecomment-1538303474 for more details about how the
original crash happened.
Use `Cow` in `{D,Subd}iagnosticMessage`.
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl From<&'static str>`, which involves a bunch of knock-on changes that require/result in call sites being a little more precise about exactly what kind of string they use to create errors, and not just `&str`. This will result in fewer unnecessary allocations, though this will not have any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to preserve the existing string imprecision. I could have used `impl Into<{D,Subd}iagnosticMessage>` in various places as is done in the compiler, but that would have required changes to *many* call sites (mostly changing `&format("...")` to `format!("...")`) which didn't seem worthwhile.
r? `@WaffleLapkin`
Rollup of 5 pull requests
Successful merges:
- #112029 (Recover upon mistyped error on typo'd `const` in const param def)
- #112037 (Add details about `unsafe_op_in_unsafe_fn` to E0133)
- #112039 (compiler: update solaris/illumos to enable tsan support.)
- #112042 (Migrate GUI colors test to original CSS color format)
- #112045 (Followup to #111973)
r? `@ghost`
`@rustbot` modify labels: rollup
Recover upon mistyped error on typo'd `const` in const param def
And add machine-applicable fix for the typo'd `const` keyword.
### Before
```
error: expected one of `,`, `:`, `=`, or `>`, found `N`
--> src/lib.rs:1:18
|
1 | pub fn bar<Const N: u8>() {}
| ^ expected one of `,`, `:`, `=`, or `>`
```
### After This PR
```
error: `const` keyword was mistyped as `Const`
--> test.rs:1:8
|
1 | fn bar<Const N: u8>() {}
| ^^^^^
|
help: use the `const` keyword
|
1 | fn bar<const N: u8>() {}
| ~~~~~
```
Fixes#111941.
Inline derived `hash`
Because most of the other derived functions are inlined: `clone`, `default`, `eq`, `partial_cmp`, `cmp`. The exception is `fmt`, but it tends to not be on hot paths as much.
r? `@ghost`
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
MIR: opt-in normalization of `BasicBlock` and `Local` numbering
This doesn't matter at all for actual codegen, but after spending some time reading pre-codegen MIR, I was wishing I didn't have to jump around so much in reading post-inlining code.
So this add two passes that are off by default for every mir level, but can be enabled (`-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals`) for humans.
Make `EarlyBinder`'s inner value private
Currently, `EarlyBinder(T)`'s inner value is public, which allows implicitly skipping the binder by indexing into the tuple struct (i.e., `x.0`). `@lcnr` suggested making `EarlyBinder`'s inner value private so users are required to explicitly call `skip_binder` (https://github.com/rust-lang/rust/issues/105779#issuecomment-1549933424) .
This PR makes the inner value private, adds `EarlyBinder::new` for constructing a new instance, and replaces uses of `x.0` with `x.skip_binder()` (or similar). It also adds some documentation to `EarlyBinder::skip_binder` explaining how to skip the binder of `&EarlyBinder<T>` to get `&T` now that the inner value is private (since previously we could just do `&x.0`).
r? `@lcnr`
Use only one shard with a single thread
This changes `Sharded` to only access a single shard using a mask set to `0` when a single thread is used, which leads to cache utilization improvements.
Performance improvement with 1 thread and `cfg(parallel_compiler)`:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7402s</td><td align="right">1.7004s</td><td align="right">💚 -2.29%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2633s</td><td align="right">0.2550s</td><td align="right">💚 -3.12%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9716s</td><td align="right">0.9482s</td><td align="right">💚 -2.41%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5679s</td><td align="right">1.5358s</td><td align="right">💚 -2.05%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">6.0569s</td><td align="right">5.9272s</td><td align="right">💚 -2.14%</td></tr><tr><td>Total</td><td align="right">10.5999s</td><td align="right">10.3666s</td><td align="right">💚 -2.20%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9760s</td><td align="right">💚 -2.40%</td></tr></table>
cc `@SparrowLii`
Don't check for misaligned raw pointer derefs inside Rvalue::AddressOf
From https://github.com/rust-lang/rust/pull/112026#issuecomment-1565686697:
rustc 1.70 (stable next week) added a Mir pass to add pointer alignment checks in debug mode. Adding these checks caused some crates to break, but that was expected, since they contain broken code (https://github.com/rust-lang/rust/issues/111487) for tracking that.
However, the checks added are slightly more aggressive than they should have been. Specifically, they also check the place in an `addr_of!` expression. Whether lack of alignment there is or isn't UB is unclear. This PR modifies the pass to not affect those cases.
I spot checked the crater regressions and the ones I saw were not the case that this PR is modifying. It still seems good to not land anything overaggressive though
Enable MatchBranchSimplification
This pass is one of the small number of benefits from `-Zmir-opt-level=3` that has motivated rustc_codegen_cranelift to use it:
19ed0aade6/compiler/rustc_codegen_cranelift/build_system/build_sysroot.rs (L244-L246)
Cranelift's motivation for this is _runtime_ performance improvements in debug builds. Lifting this pass all the way to `-Zmir-opt-level=1` seems to come without significant perf overhead, so that's what I'm suggesting here.
Add support for LLVM SafeStack
Adds support for LLVM [SafeStack] which provides backward edge control
flow protection by separating the stack into two parts: data which is
only accessed in provable safe ways is allocated on the normal stack
(the "safe stack") and all other data is placed in a separate allocation
(the "unsafe stack").
SafeStack support is enabled by passing `-Zsanitizer=safestack`.
[SafeStack]: https://clang.llvm.org/docs/SafeStack.html
cc `@rcvalle` #39699
Add warn-by-default lint when local binding shadows exported glob re-export item
This PR introduces a warn-by-default rustc lint for when a local binding (a use statement, or a type declaration) produces a name which shadows an exported glob re-export item, causing the name from the exported glob re-export to be hidden (see #111336).
### Unresolved Questions
- [x] ~~Is this approach correct? While it passes the UI tests, I'm not entirely convinced it is correct.~~ Seems to be ok now.
- [x] ~~What should the lint be called / how should it be worded? I don't like calling `use x::*;` or `struct Foo;` a "local binding" but they are `NameBinding`s internally if I'm not mistaken.~~ ~~The lint is called `local_binding_shadows_glob_reexport` for now, unless a better name is suggested.~~ `hidden_glob_reexports`.
Fixes#111336.
rustc driver: Remove argument 0 before at-expansion to prevent ICE
Under Unix-based operating systems, when I execute rustc by setting argv0 to ``@/dev/null`,` it will expand command-line arguments from this file, leading to an empty arglist, which then triggers an ICE by trying to remove first argument.
The panic message is this:
```
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', compiler/rustc_driver/src/lib.rs:972:17
```
My fix is to remove the first argument before expanding arguments.
<details>
<summary>Full backtrace</summary>
```sh
% (exec -a `@/dev/null` `rustup which rustc`)
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', compiler/rustc_driver/src/lib.rs:972:17
stack backtrace:
0: 0x7fcec776659a - std::backtrace_rs::backtrace::libunwind::trace::h595f06c70adcc478
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7fcec776659a - std::backtrace_rs::backtrace::trace_unsynchronized::h177a0149c76cdde9
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7fcec776659a - std::sys_common::backtrace::_print_fmt::hc0701fd2c3530c58
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:65:5
3: 0x7fcec776659a - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd4cd115d8750fd6c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:44:22
4: 0x7fcec77c839e - core::fmt::write::h93e2f5923c7eca08
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/fmt/mod.rs:1213:17
5: 0x7fcec7756be5 - std::io::Write::write_fmt::h8162dbb45f0b9e62
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/io/mod.rs:1682:15
6: 0x7fcec7766365 - std::sys_common::backtrace::_print::h1835ef8a8f9066da
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:47:5
7: 0x7fcec7766365 - std::sys_common::backtrace::print::hcb5e6388b9235f41
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:34:9
8: 0x7fcec776912f - std::panicking::default_hook::{{closure}}::h9c084969ccf9a722
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:267:22
9: 0x7fcec7768e6b - std::panicking::default_hook::h68fa2ba3c3c6c12f
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:286:9
10: 0x7fcecaab56e4 - <rustc_driver[f4ad927b3c57833d]::DEFAULT_HOOK::{closure#0}::{closure#0} as core[d16e85342ea223d9]::ops::function::FnOnce<(&core[d16e85342ea223d9]::panic::panic_info::PanicInfo,)>>::call_once::{shim:vtable#0}
11: 0x7fcec776996a - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h4e6ced11e07d8b24
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/alloc/src/boxed.rs:2002:9
12: 0x7fcec776996a - std::panicking::rust_panic_with_hook::h8d5c434518ef298c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:692:13
13: 0x7fcec77696e9 - std::panicking::begin_panic_handler::{{closure}}::hf33414f5dabf6faf
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:579:13
14: 0x7fcec7766a4c - std::sys_common::backtrace::__rust_end_short_backtrace::hc50389427413bb75
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:137:18
15: 0x7fcec77693f2 - rust_begin_unwind
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:575:5
16: 0x7fcec77c4d43 - core::panicking::panic_fmt::h2de7a7938f816de8
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/panicking.rs:64:14
17: 0x7fcec77cb492 - core::slice::index::slice_start_index_len_fail_rt::h0c87d85ce11d10f6
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/slice/index.rs:53:5
18: 0x7fcec77cb416 - core::slice::index::slice_start_index_len_fail::h504609f2a6b168d1
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/slice/index.rs:41:9
19: 0x7fceca0eca1f - rustc_driver[f4ad927b3c57833d]::handle_options
20: 0x7fceca0e037f - <rustc_driver[f4ad927b3c57833d]::RunCompiler>::run
21: 0x7fceca0dfd0d - <core[d16e85342ea223d9]::panic::unwind_safe::AssertUnwindSafe<rustc_driver[f4ad927b3c57833d]::main::{closure#0}> as core[d16e85342ea223d9]::ops::function::FnOnce<()>>::call_once
22: 0x7fceca17ce89 - rustc_driver[f4ad927b3c57833d]::main
23: 0x564f5f008a87 - rustc_main[f164605d1302e295]::main
24: 0x564f5f008973 - std[3da461b304582a2c]::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
25: 0x564f5f008969 - <std[3da461b304582a2c]::rt::lang_start<()>::{closure#0} as core[d16e85342ea223d9]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
26: 0x7fcec774795c - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h699977d052768608
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/ops/function.rs:287:13
27: 0x7fcec774795c - std::panicking::try::do_call::h4e121e623c70f903
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:483:40
28: 0x7fcec774795c - std::panicking::try::hf9d919e062bc178a
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:447:19
29: 0x7fcec774795c - std::panic::catch_unwind::h7a7b12272684cb97
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panic.rs:140:14
30: 0x7fcec774795c - std::rt::lang_start_internal::{{closure}}::hd96b0eb4844b8762
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/rt.rs:148:48
31: 0x7fcec774795c - std::panicking::try::do_call::h1af1f88f4f92a22c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:483:40
32: 0x7fcec774795c - std::panicking::try::hf20d7abea7f0f097
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:447:19
33: 0x7fcec774795c - std::panic::catch_unwind::hb0e084c3a9c042e4
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panic.rs:140:14
34: 0x7fcec774795c - std::rt::lang_start_internal::hca9d5c7277f5b67c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/rt.rs:148:20
35: 0x564f5f008ab7 - main
36: 0x7fcec74a1790 - <unknown>
37: 0x7fcec74a184a - __libc_start_main
38: 0x564f5f00899e - <unknown>
39: 0x0 - <unknown>
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.68.0 (2c8cc3432 2023-03-06) running on x86_64-unknown-linux-gnu
query stack during panic:
end of query stack
```
</details>
I also checked if I can trigger a similar problem by passing empty argument list to `execve`, but at least under Linux, it seems to always insert an empty first argument if there are none.
Perform MIR type ops locally in new solver
The new solver already does caching, and it's generally more correct to be using the infcx of the MIR typeck (which has the defining anchor set correctly and has already initialized all the opaques from HIR typeck).
This is based on #111918 so look at the final 3 commits.
This actually causes some tests to go from passing to failing, and failing to passing. Here's the full diff: https://www.diffchecker.com/hB4bh1A9/
Putting this up for exposure mostly.
r? `@lcnr`
fix for `Self` not respecting tuple Ctor privacy
This PR fixes#111220 by checking the privacy of tuple constructors using `Self`, so the following code now errors
```rust
mod my {
pub struct Foo(&'static str);
}
impl AsRef<str> for my::Foo {
fn as_ref(&self) -> &str {
let Self(s) = self; // previously compiled, now errors correctly
s
}
}
```
Change ty and const error's pretty printing to be in braces
`[const error]` and `[type error]` are slightly confusing since they look like either a slice with an error type for the element ty or a slice with a const argument as the type ???. This PR changes them to display as `{const error}` and `{type error}` similar to `{integer}`.
This does not update the `Debug` impls for them which is done in #111988.
I updated some error logic to avoid printing the substs of trait refs when unable to resolve an assoc item for them, this avoids emitting errors with `{type error}` in them. The substs are not relevant for these errors since we don't take into account the substs when resolving the assoc item.
r? ``@compiler-errors``
improve error message for calling a method on a raw pointer with an unknown pointee
The old error message had very confusing wording.
Also added some more test cases besides the single edition test.
r? `@compiler-errors`
Adds support for LLVM [SafeStack] which provides backward edge control
flow protection by separating the stack into two parts: data which is
only accessed in provable safe ways is allocated on the normal stack
(the "safe stack") and all other data is placed in a separate allocation
(the "unsafe stack").
SafeStack support is enabled by passing `-Zsanitizer=safestack`.
[SafeStack]: https://clang.llvm.org/docs/SafeStack.html
Previously, we used the following info to determine whether to load the crate:
1. The METADATA_HEADER, which includes a METADATA_VERSION constant
2. The embedded rustc version
3. Various metadata in the `CrateRoot`, including the SVH
This worked ok most of the time. Unfortunately, when building locally the rustc version is always
the same because `omit-git-hash` is on by default. That meant that we depended only on 1 and 3, and
we are not very good about bumping METADATA_VERSION (it's currently at 7) so in practice we were
only depending on 3. `CrateRoot` is a very large struct and changes somewhat regularly, so this led
to a steady stream of crashes from trying to load it.
Change the logic to add an intermediate step between 2 and 3: introduce a new `CrateHeader` struct
that contains only the minimum info needed to decide whether the crate should be loaded or not. That
avoids having to load all of `CrateRoot`, which in practice means we should crash much less often.
Note that this works because the SVH should be different between any two dependencies, even if the
compiler has changed, because we use `-Zbinary-dep-depinfo` in bootstrap. See
https://github.com/rust-lang/rust/pull/111329#issuecomment-1538303474 for more details about how the
original crash happened.
Rollup of 5 pull requests
Successful merges:
- #111384 (Fix linking Mac Catalyst by including LC_BUILD_VERSION in object files)
- #111899 (CGU cleanups)
- #111940 (Clarify safety concern of `io::Read::read` is only relevant in unsafe code)
- #111947 (Add test for RPIT defined with different hidden types with different substs)
- #111951 (Correct comment on privately uninhabited pattern.)
Failed merges:
- #111954 (improve error message for calling a method on a raw pointer with an unknown pointee)
r? `@ghost`
`@rustbot` modify labels: rollup