It might make sense to allow this in the future, if we add values that aren't
mutually exclusive, but for now having multiple coverage attributes on one item
is useless.
Rollup of 9 pull requests
Successful merges:
- #126177 (Add hard error and migration lint for unsafe attrs)
- #126298 (Promote loongarch64-unknown-linux-musl to Tier 2 with host tools)
- #126455 (For [E0308]: mismatched types, when expr is in an arm's body, not add semicolon ';' at the end of it.)
- #126754 (Implement `use<>` formatting in rustfmt)
- #126807 (std::unix::fs: copy simplification for apple.)
- #126845 (Weekly `cargo update`)
- #126849 (Fix 32-bit Arm reg classes by hierarchically sorting them)
- #126854 (std::unix::os::home_dir: fallback's optimisation.)
- #126888 (Remove stray println from rustfmt's `rewrite_static`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove stray println from rustfmt's `rewrite_static`
r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong.
This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this.
Fix https://github.com/rust-lang/rustfmt/issues/6210
Fix https://github.com/rust-lang/rust/issues/126887
Fix 32-bit Arm reg classes by hierarchically sorting them
We were rejecting legal `asm!` because we were asking for the "greatest" feature that includes a register class, instead of the "least" feature that includes a register class. This was only revealed on certain 32-bit Arm targets because not all have the same register limitations.
This is a somewhat hacky solution, but other solutions would require potentially rearchitecting how the internals of parsing or rejecting register classes work for all targets.
Fixes#126797
r? ``@Amanieu``
std::unix::fs: copy simplification for apple.
since we do support from macOs Sierra, we avoid the little runtime overhead with the fclonefileat symbol check.
Implement `use<>` formatting in rustfmt
This PR implements formatting for precise-capturing `use<>` syntax as proposed in https://github.com/rust-lang/rust/pull/126753.
The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier.
I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If ``@rust-lang/rustfmt`` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive.
This implementation is otherwise rather straightforward.
Tracking:
- https://github.com/rust-lang/rust/issues/123432
For [E0308]: mismatched types, when expr is in an arm's body, not add semicolon ';' at the end of it.
For [E0308]: mismatched types, when expr is in an arm's body, and it is the end expr without a semicolon of the block, not add semicolon ';' at the end of it.
fixes#126222
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Add hard error and migration lint for unsafe attrs
More implementation work for https://github.com/rust-lang/rust/issues/123757
This adds the migration lint for unsafe attributes, as well as making it a hard error in Rust 2024.
Remove confusing `use_polonius` flag and do less cloning
The `use_polonius` flag is both redundant and confusing since every function it's propagated to also checks if `all_facts` is `Some`, the true test of whether to generate Polonius facts for Polonius or for external consumers. This PR makes that path clearer by simply doing away with the argument and handling the logic in precisely two places: where facts are populated (check for `Some`), and where `all_facts` are initialised. It also delays some statements until after that check to avoid the miniscule performance penalty of executing them when Polonius is disabled.
This also addresses `@lqd's` concern in #125652 by reducing the size of what is cloned out of Polonius facts to just the facts being added, as opposed to the entire vector of potential inputs, and added descriptive comments.
*Reviewer note*: the comments in `add_extra_drop_facts` should be inspected by a reviewer, in particular the one on [L#259](https://github.com/rust-lang/rust/compare/master...amandasystems:you-dropped-this-again?expand=1#diff-aa727290e6670264df2face84f012897878e11a70e9c8b156543cfcd9619bac3R259) in this PR, which should be trivial for someone with the right background knowledge to address.
I also included some lints I found on the way there that I couldn't help myself from addressing.
Rollup of 9 pull requests
Successful merges:
- #126230 (tidy: skip submodules if not present for non-CI environments)
- #126612 (Update outdated README in build-manifest.)
- #126616 (less bootstrap warnings)
- #126663 (remove `GIT_DIR` handling in pre-push hook)
- #126830 (make unsized_fn_params an internal feature)
- #126833 (don't ICE when encountering an extern type field during validation)
- #126837 (delegation: Do not crash on qpaths without a trait)
- #126851 (Rework pattern and expression nonterminal kinds.)
- #126862 (Add needs-symlink directive to compiletest)
r? `@ghost`
`@rustbot` modify labels: rollup
Add needs-symlink directive to compiletest
This is an alternative to #126846 that allows running symlink tests on Windows in CI but will ignore them locally if symlinks aren't available. A future improvement would be to check that the `needs-symlink` directive is used in rmake files that call `create_symlink` but this is just a quick PR to unblock Windows users who want to run tests locally without enabling symlinks.
Rework pattern and expression nonterminal kinds.
Some tweaks to `NonterminalKind` that will assist with #124141. Details in the individual commits.
r? compiler-errors
cc ```@eholk```
less bootstrap warnings
This is how the build logs looks like currently:
```sh
$ x build
Building bootstrap
Compiling bootstrap v0.0.0 (/home/nimda/devspace/onur-ozkan/rust/src/bootstrap)
Finished `dev` profile [unoptimized] target(s) in 3.43s
WARNING: no codegen-backends config matched the requested path to build a codegen backend. HELP: add backend to codegen-backends in config.toml.
WARNING: creating symbolic link `/home/nimda/devspace/.other/rustc-builds/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/rustc-src/rust` to `/home/nimda/devspace/onur-ozkan/rust` failed with File exists (os
error 17)
Creating a sysroot for stage2 compiler (use `rustup toolchain link 'name' build/host/stage2`)
WARNING: creating symbolic link `/home/nimda/devspace/.other/rustc-builds/build/x86_64-unknown-linux-gnu/ci-rustc-sysroot/lib/rustlib/rustc-src/rust` to `/home/nimda/devspace/onur-ozkan/rust` failed with File e
xists (os error 17)
Building tool rustdoc (stage1 -> stage2, x86_64-unknown-linux-gnu)
Compiling rustdoc v0.0.0 (/home/nimda/devspace/onur-ozkan/rust/src/librustdoc)
Compiling rustdoc-tool v0.0.0 (/home/nimda/devspace/onur-ozkan/rust/src/tools/rustdoc)
Finished `release` profile [optimized + debuginfo] target(s) in 13.57s
Build completed successfully in 0:00:17
```
This PR removes artifact linking warnings and only shows the codegen-backend warning if explicitly called or during Dist or Install steps.
tidy: skip submodules if not present for non-CI environments
Right now tidy requires rustc-perf to be fetched as it checks its license, but this doesn't make sense for most contributors since rustc-perf is a dist-specific tool and its license will not change frequently, especially during compiler development. This PR makes tidy to skip rustc-perf if it's not fetched and if it's not running in CI.
Applies https://github.com/rust-lang/rust/pull/126225#issuecomment-2158143674 and reverts #126225.
Replace `f16` and `f128` pattern matching stubs with real implementations
This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now.
r? `@Nadrieril`
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.
This also fixes some missing range and match handling in `rustc_middle`.
