Previously, we would normalize *all* of
- the absolute path to the repository checkout
- the /rustc/$sha for stage1 (if `remap-debuginfo` was enabled)
- the /rustc/$sha for download-rustc
- the sysroot for download-rustc
Now, we consistently only normalize /rustc/FAKE_PREFIX. Not only is this
much simpler, but it also avoids ongoing maintenance for download-rustc
and makes it much less likely that tests break by accident.
- Change `tests/ui/track-diagnostics/track6.rs` to use a relative path
instead of an absolute one. I am not actually sure why `track_caller`
works here, but it does seem to work 🤷
- Pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` to all
suites, not just UI. In particular, mir-opt tests emit /rustc/ paths
in their output.
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.
Improve startup time of bootstrap
~~If the user has a `build/host` symlink set up, we can determine the target triple by reading it rather than invoking rustc. This significantly reduces startup time of bootstrap once any kind of build has been done~~
New approach explained below
```
➜ hyperfine -p 'git checkout -q master' -N './x.py -h' -r 50
Benchmark 1: ./x.py -h
Time (mean ± σ): 140.7 ms ± 2.6 ms [User: 99.9 ms, System: 39.3 ms]
Range (min … max): 136.8 ms … 149.6 ms 50 runs
➜ rust git:(master) hyperfine -p 'git checkout -q speedup-bootstrap-py' -N './x.py -h' -r 50
Benchmark 1: ./x.py -h
Time (mean ± σ): 95.2 ms ± 1.5 ms [User: 67.7 ms, System: 26.7 ms]
Range (min … max): 92.9 ms … 99.6 ms 50 runs
```
Also a small microoptimisation in using string splitting rather than regex when reading toml, which saves a few more milliseconds (2-5 testing locally), but less important.
Profiling shows the remaining runtime is around half setting up the Python runtime, and the vast majority of the remaining time is spent in subprocess building and running bootstrap itself, so probably can't be improved much further.
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
Fix linking Mac Catalyst by including LC_BUILD_VERSION in object files
Hello. My first rustc PR!
Issue #106021 prevents Rust code from being linked into Mac Catalyst applications. Apple's LD has started requiring object files to contain version information about the platform they were built for, such as:
* the "deployment target" (minimum supported OS version),
* the SDK version
* the type of the platform (macOS/iOS/catalyst/tvOS/watchOS all have a different number).
This is currently only enforced when building for Mac Catalyst.
Rust uses the `object` crate which added support for including this information starting with `0.31.0`. ~~I upgraded it along with `thorin-dwp` so that everything depends on 0.31.
Apparently 0.31 [pulls in](https://github.com/gimli-rs/object/issues/463) `ruzstd` due to a [new ELF standard](https://maskray.me/blog/2022-09-09-zstd-compressed-debug-sections) because its `compression` feature is enabled by thorin. If you find this objectionable, let me know what the best way to avoid pulling in those dependencies might be.~~
**(`object` upgraded in https://github.com/rust-lang/rust/pull/111413)**
I then added two commits:
* The first one adds very basic, hard-coded support for calling `set_macho_build_version` for `-macabi` (Catalyst) targets, where it claims deployment target of Catalyst 14.0 and SDK of 16.2.
* The second weaves the versioning through `rust_target::spec::TargetOptions`, so that we can stick to specifying all target-related info in one place.
Kudos to ``@ara4n`` for writing [this gist](https://gist.github.com/ara4n/320a53ea768aba51afad4c9ed2168536).
This 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
}
}
```
Ensure Fluent messages are in alphabetical order
Fixes#111847
This adds a tidy check to ensure Fluent messages are in alphabetical order, as well as sorting all existing messages. I think the error could be worded better, would appreciate suggestions.
<details>
<summary>Script used to sort files</summary>
```py
import sys
import re
fn = sys.argv[1]
with open(fn, 'r') as f:
data = f.read().split("\n")
chunks = []
cur = ""
for line in data:
if re.match(r"^([a-zA-Z0-9_]+)\s*=\s*", line):
chunks.append(cur)
cur = ""
cur += line + "\n"
chunks.append(cur)
chunks.sort()
with open(fn, 'w') as f:
f.write(''.join(chunks).strip("\n\n") + "\n")
```
</details>
Rollup of 7 pull requests
Successful merges:
- #107522 (Add Median of Medians fallback to introselect)
- #111152 (update `pulldown-cmark` to `0.9.3`)
- #111757 (Consider lint check attributes on match arms)
- #111831 (Always capture slice when pattern requires checking the length)
- #111929 (Don't print newlines in APITs)
- #111945 (Migrate GUI colors test to original CSS color format)
- #111950 (Remove ExpnKind::Inlined.)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't print newlines in APITs
This is kind of a hack, but it gets the job done because the only "special" formatting that (afaict) `rustc_ast_pretty` does is break with newlines sometimes.
Fixesrust-lang/measureme#207
Always capture slice when pattern requires checking the length
Fixes#111751
cc ``@zirconium-n,`` I see you were assigned to this but I've fixed some similar issues in the past and had an idea on how to investigate this.
Consider lint check attributes on match arms
Currently, lint check attributes on match arms have no effect for some lints. This PR makes some lint passes to take those attributes into account.
- `LateContextAndPass` for late lint doesn't update `last_node_with_lint_attrs` when it visits match arms. This leads to lint check attributes on match arms taking no effects on late lints that operate on the arms' pattern:
```rust
match value {
#[deny(non_snake_case)]
PAT => {} // `non_snake_case` only warned due to default lint level
}
```
To be honest, I'm not sure whether this is intentional or just an oversight. I've dug the implementation history and searched up issues/PRs but couldn't find any discussion on this.
- `MatchVisitor` doesn't update its lint level when it visits match arms. This leads to check lint attributes on match arms taking no effect on some lints handled by this visitor, namely: `bindings_with_variant_name` and `irrefutable_let_patterns`.
This seems to be a fallout from #108504. Before 05082f57af, when the visitor operated on HIR rather than THIR, check lint attributes for the said lints were effective. [This playground][play] compiles successfully on current stable (1.69) but fails on current beta and nightly.
I wasn't sure where best to place the test for this. Let me know if there's a better place.
[play]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=38432b79e535cb175f8f7d6d236d29c3
[play-match]: https://play.rust-lang.org/?version=beta&mode=debug&edition=2021&gist=629aa71b7c84b269beadeba664e2221d
