Update cargo
18 commits in e75214ea4936d2f2c909a71a1237042cc0e14b07..0310497822a7a673a330a5dd068b7aaa579a265e
2024-10-25 16:34:32 +0000 to 2024-11-01 19:27:56 +0000
- Add more metadata to `rustc_fingerprint` (rust-lang/cargo#14761)
- test(rustfix): switch to a simpler case for dedup-suggestions (rust-lang/cargo#14765)
- chore(deps): update rust crate security-framework to v3 (rust-lang/cargo#14766)
- chore(deps): update rust crate gix to 0.67.0 (rust-lang/cargo#14762)
- fix(util): Respect all `..`s in `normalize_path` (rust-lang/cargo#14750)
- test(doc): Resolve flaky test (rust-lang/cargo#14760)
- refactor(test): Remove dead 'expect_stdout_contains_n' check (rust-lang/cargo#14759)
- add unstable -Zroot-dir flag to configure the path from which rustc should be invoked (rust-lang/cargo#14752)
- docs(resolver): Further v3 prep (rust-lang/cargo#14753)
- fix: track version in fingerprint dep-info files (rust-lang/cargo#14751)
- test: Remove unused msrv-policy (rust-lang/cargo#14748)
- download targeted transitive deps of with artifact deps' target platform (rust-lang/cargo#14723)
- Remove requirement for --target when invoking Cargo with -Zbuild-std (rust-lang/cargo#14317)
- docs(fingerprint): document the encoding of Cargo's depinfo (rust-lang/cargo#14745)
- Allow build scripts to report error messages through `cargo::error` (rust-lang/cargo#14743)
- fix(publish): Downgrade version-exists error to warning on dry-run (rust-lang/cargo#14742)
- fix: clean up for deprecated and removed commands (rust-lang/cargo#14739)
- Deprecate `cargo verify-project` (rust-lang/cargo#14736)
rustdoc: Directly use rustc_abi instead of reexports
rustc_target reexports a lot of things that are in rustc_abi, but that will be over soon and now is probably a good time to switch. Uses of rustc_target remain where they inquire about the target tuple.
Remove support for `-Zprofile` (gcov-style coverage instrumentation)
Tracking issue: #42524
MCP: https://github.com/rust-lang/compiler-team/issues/798
---
This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.
(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)
Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
- #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
rustc_target reexports a lot of things that are in rustc_abi, but
that will be over soon and now is probably a good time to switch.
Uses of rustc_target remain where they inquire about the target tuple.
Remove support for decompressing dylib metadata
We haven't been compressing dylib metadata for a while now. Removing decompression support will regress error messages about an incompatible rustc version being used, but dylibs are pretty rare anyway.
Fixes https://github.com/rust-lang/rust-analyzer/issues/18451
Use protected visibility when building rustc with LLD
https://github.com/rust-lang/compiler-team/issues/782
I wasn't sure about having two commits in a PR, but I figured, at least initially it might make sense to discuss these commits together. Happy to squash, or move the second commit to a separate PR.
I contemplated trying to enable protected visibility for more cases when LLD will be used other than just `-Zlinker-features=+lld`, but that would be more a complex change that probably still wouldn't cover all cases when LLD is used, so went with the simplest option of just checking if the linker-feature is enabled.
r? lqd
macOS: Document the difference between Clang's `-darwin` and `-macosx` targets
`rustc`'s `*-apple-darwin` targets are badly named (they should've been called `*-apple-macos`), and this causes confusion wrt. the similarly named but somewhat incompatible Clang targets.
So let's document the difference to at least make things a _little_ easier on our users.
``@rustbot`` label O-macos A-docs
continue `TypingMode` refactor
There are still quite a few places which (indirectly) rely on the `Reveal` of a `ParamEnv`, but we're slowly getting there
r? `@compiler-errors`
Rollup of 5 pull requests
Successful merges:
- #130693 (Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests)
- #132316 (CI: use free runners for 3 fast windows jobs)
- #132354 (Add `lp64e` RISC-V ABI)
- #132395 (coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable)
- #132396 (CI: use free runners for x86_64-gnu-tools and x86_64-rust-for-linux)
r? `@ghost`
`@rustbot` modify labels: rollup
We haven't been compressing dylib metadata for a while now. Removing
decompression support will regress error messages about an incompatible
rustc version being used, but dylibs are pretty rare anyway.
Remove region from adjustments
It's not necessary to store this region, because it's only used in THIR and MemCat/ExprUse, both of which already basically only deal with erased regions anyways.
force-recompile library changes on download-rustc="if-unchanged"
This makes the download-rustc="if-unchanged" option more functional and useful for library developers.
Implements the second item from [this tracking issue](https://github.com/rust-lang/rust/issues/131744).
Rename `rustc_abi::Abi` to `BackendRepr`
Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.
Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
rustdoc: make doctest span tweak a 2024 edition change
Fixes#132203
This is a compatibility hack, because I think the new behavior is better. When an A `include_str!` B, and B `include_str!` C, the path to C should be resolved relative to B, not A. That's how `include!` itself works, so that's how `include_str!` with should work.
Remap impl-trait lifetimes on HIR instead of AST lowering
Current AST->HIR lowering goes out of its way to remap lifetimes for opaque types. This is complicated and leaks into upstream and downstream code.
This PR stops trying to be clever during lowering, and prefers to do this remapping during the HIR->ty lowering. The remapping computation easily fits into the bound var resolution code. Its result can be used in by `generics_of` and `hir_ty_lowering::new_opaque` to add the proper parameters and arguments.
See an example on the doc for query `opaque_captured_lifetimes`.
Based on https://github.com/rust-lang/rust/pull/129244/
Fixes https://github.com/rust-lang/rust/issues/125249
Fixes https://github.com/rust-lang/rust/issues/126850
cc `@compiler-errors` `@spastorino`
r? `@petrochenkov`
compiletest: improve robustness of LLVM version handling
Previously, `extract_llvm_versions` did some gymnastics for llvm versions by combining `(major, minor, patch)` into a combined version integer, but that is not very robust and made it difficult to add `max-llvm-major-version`. This PR tries to:
- Improve llvm version handling robustness by parsing and representing the version as a semver. We intentionally deviate from strict semver standards by allowing omission of minor and patch versions. They default to `0` when absent. This is for convenience to allow the user to write e.g. `//@ min-llvm-version: 18` instead of having to spell out the full `major.minor.patch` semver string `//@ min-llvm-verison: 18.0.0`.
- Adjust some panic messages to include a bit more context about *why* the version string was rejected.
Prerequisite for #132310.
r? bootstrap (or compiler)
rustdoc: Remove usage of `allow(unused)` attribute on `no_run` merged doctests
Fixes [#130681](https://github.com/rust-lang/rust/issues/130681).
It fixes the behaviour difference with the current doctests.
r? ``@notriddle``
The RFC for arbitrary self types v2 declares that we should reject
"generic" self types. This commit does so.
The definition of "generic" was unclear in the RFC, but has been
explored in
https://github.com/rust-lang/rust/issues/129147
and the conclusion is that "generic" means any `self` type which
is a type parameter defined on the method itself, or references
to such a type.
This approach was chosen because other definitions of "generic"
don't work. Specifically,
* we can't filter out generic type _arguments_, because that would
filter out Rc<Self> and all the other types of smart pointer
we want to support;
* we can't filter out all type params, because Self itself is a
type param, and because existing Rust code depends on other
type params declared on the type (as opposed to the method).
This PR decides to make a new error code for this case, instead of
reusing the existing E0307 error. This makes the code a
bit more complex, but it seems we have an opportunity to provide
specific diagnostics for this case so we should do so.
This PR filters out generic self types whether or not the
'arbitrary self types' feature is enabled. However, it's believed
that it can't have any effect on code which uses stable Rust, since
there are no stable traits which can be used to indicate a valid
generic receiver type, and thus it would have been impossible to
write code which could trigger this new error case.
It is however possible that this could break existing code which
uses either of the unstable `arbitrary_self_types` or
`receiver_trait` features. This breakage is intentional; as
we move arbitrary self types towards stabilization we don't want
to continue to support generic such types.
This PR adds lots of extra tests to arbitrary-self-from-method-substs.
Most of these are ways to trigger a "type mismatch" error which
9b82580c73/compiler/rustc_hir_typeck/src/method/confirm.rs (L519)
hopes can be minimized by filtering out generics in this way.
We remove a FIXME from confirm.rs suggesting that we make this change.
It's still possible to cause type mismatch errors, and a subsequent
PR may be able to improve diagnostics in this area, but it's harder
to cause these errors without contrived uses of the turbofish.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519https://github.com/rust-lang/rust/issues/44874
r? @wesleywiser
