[`default_constructed_unit_structs`]: do not lint on type alias paths
Fixes#10755.
Type aliases cannot be used as a constructor, so this lint should not trigger in those cases.
I also changed `clippy_utils::is_ty_alias` to also consider associated types since [they kinda are type aliases too](48ec50ae39/compiler/rustc_resolve/src/late/diagnostics.rs (L1520)).
changelog: [`default_constructed_unit_structs`]: do not lint on type alias paths
rustup
I don't know what happened here: efb9c30ed2 (r115119947) that commit broke our tests I think. I don't know why it didn't break on the rustc side.
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
}
}
```
This reverts commit 827f656ebb.
Incremental is not sound to use across stages. Arbitrary changes to the compiler can invalidate the
incremental cache - even changes to normal queries, not incremental itself! - and we do not
currently enable `incremental-verify-ich` in bootstrap. Since 2018, we highly recommend and nudge
users towards stage 1 builds instead of stage 2, and using `keep-stage` for anything other than
libstd is very rare.
I don't think the risk of unsoundness is worth the very minor speedup when building libstd. Disable
incremental to avoid spurious panics and miscompilations when building with the stage 1 and 2
sysroot.
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>
[`unused_async`]: do not consider `await` in nested `async` blocks as used
Fixes#10800.
This PR makes sure that `await` expressions inside of inner `async` blocks don't prevent the lint from triggering.
For example
```rs
async fn foo() {
async {
std::future::ready(()).await;
}
}
```
Even though there *is* a `.await` expression in this function, it's contained in an async block, which means that the enclosing function doesn't need to be `async` too.
changelog: [`unused_async`]: do not consider `await` in nested `async` blocks as used
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
