Remove unnecessary impl sorting in queries and metadata
Removes unnecessary impl sorting because queries already return their keys in HIR definition order: https://github.com/rust-lang/rust/issues/120371#issuecomment-1926422838
r? `@cjgillot` or `@lcnr` -- unless I totally misunderstood what was being asked for here? 😆fixes#120371
Update cargo
9 commits in a2b58c3dad4d554ba01ed6c45c41ff85390560f2..5f6b9a92201d78af75dc24f14662c3e2dacbbbe1
2024-07-16 00:52:02 +0000 to 2024-07-19 18:09:17 +0000
- Add `TomlPackage::new`, `Default` for `TomlWorkspace` (rust-lang/cargo#14271)
- fix(test): Move 'cargo_home' from 'install' to 'paths' (rust-lang/cargo#14270)
- fix(test)!: Clarify extension trait role with rename (rust-lang/cargo#14269)
- feat(test): Re-export ProcessBuilder (rust-lang/cargo#14268)
- fix(test): Move path2url to CargoPathExt::to_url (rust-lang/cargo#14266)
- Fix passing of links-overrides with target-applies-to-host and an implicit target (rust-lang/cargo#14205)
- fix(toml): Improve error on missing package and workspace (rust-lang/cargo#14261)
- Migrate global_cache_tracker snapbox (rust-lang/cargo#14244)
- make summary sync by using Arc not Rc (rust-lang/cargo#14260)
Migrate 9 more very similar FFI `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
For the tracking issue:
- return-non-c-like-enum-from-c
- pass-non-c-like-enum-to-c
- c-static-dylib
- c-static-rlib
- extern-fn-generic
- extern-fn-with-union
- lto-no-link-whole-rlib
- linkage-attr-on-static
- issue-28595
Cleanup rmake.rs setup in compiletest
While debugging rmake.rs tests I realized that the rmake.rs setup itself in compiletest is very messy and confused. Now that I know some of the bootstrap steps and the rmake.rs tests themselves better, I realized there are cleanups that are possible:
- Rework how `source_root` and `build_root` are calculated. They should now be less fragile then before.
- Shuffle around path calculations to make them more logically grouped and closer to eventual use site(s).
- Cleanup executable extension calculation with `std::env::consts::EXE_EXTENSION`.
- Cleanup various dylib search path handling: renamed variables to better reflect their purpose, minimized mutability scope of said variables.
- Prune useless env vars passed to both `rustc` and recipe binary commands.
- Vastly improve the documentation for the setup of rmake.rs tests, including assumed bootstrap-provided build layouts, rmake.rs test layout, dylib search paths, intended purpose of passed env vars and the `COMPILETEST_FORCE_STAGE0=1 ./x test run-make --stage 0` stage0 sysroot special handling.
This PR is best reviewed commit-by-commit.
Fixes https://github.com/rust-lang/rust/issues/127920.
r? bootstrap (or Kobzol, or Mark, or T-compiler)
try-job: aarch64-apple
try-job: armhf-gnu
try-job: dist-x86_64-linux
try-job: test-various
try-job: x86_64-mingw
try-job: x86_64-msvc
try-job: x86_64-gnu-llvm-18
Add `wasm32-wasip2` to `build-manifest` tool
This is an accidental omission of mine from #126967 which means that `rustup target add wasm32-wasip2` isn't working on today's nightlies.
run_make_support: skip rustfmt for lib.rs
To avoid them getting reordered once https://github.com/rust-lang/rust/pull/125443 goes through.
r? ``@nnethercote`` (since you were working on this)
use precompiled rustdoc with CI rustc
When CI rustc is enabled and rustdoc sources are unchanged, we can use the precompiled rustdoc from the CI rustc's sysroot. This speeds up bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.
This is important for other tests that have various things like modes,
revisions and the like. These features are not supported in run-make
tests, so we don't need the double layering.
Update jsondocck directives to follow ui_test-style
Context: Comment chain in #125813.
Follow-up to #126788.
Use the same temporary approach of "double parsing" until we figure out how we want to support compiletest/ui_test directive "add-ons" for child test runners like HtmlDocCk and JsonDocCk.
I didn't touch much of jsondocck because I want to refactor it some other time (for robustness, maintainability and better diagnostics; basically by following a similar design of my WIP HtmlDocCk-next, cc #125780).
r? `@GuillaumeGomez`
Cleanup dll/exe filename calculations in `run_make_support`
Use `std::env::consts` constants since now we have access to them (unlike in Makefiles!) ^^
cc `@bzEq` (this is one of the places in our test suites that tries to compute e.g. dylib extension; using `std::env::consts::DLL_EXTENSION` should correctly return `a` for AIX)
r? `@fmease` (thank you for the suggestion in https://github.com/rust-lang/rust/pull/127760#discussion_r1678079698, this also improves correctness for the support library!)
try-job: aarch64-apple
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc
try-job: x86_64-gnu-llvm-18
interpret: add sanity check in dyn upcast to double-check what codegen does
For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.)
This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path.
r? ``@oli-obk``
Rollup of 7 pull requests
Successful merges:
- #121533 (Handle .init_array link_section specially on wasm)
- #127825 (Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake)
- #127891 (Tweak suggestions when using incorrect type of enum literal)
- #127902 (`collect_tokens_trailing_token` cleanups)
- #127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake)
- #127935 (Change `binary_asm_labels` to only fire on x86 and x86_64)
- #127953 ([compiletest] Search *.a when getting dynamic libraries on AIX)
r? `@ghost`
`@rustbot` modify labels: rollup
Represent type-level consts with new-and-improved `hir::ConstArg`
### Summary
This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:
- Add `current_def_id_parent` to `LoweringContext`
This is needed to track anon const parents properly once we implement
`ConstArgKind::Path` (which requires moving anon const def-creation
outside of `DefCollector`).
- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.
- Use `ConstArg` for all instances of const args. Specifically, use it instead
of `AnonConst` for assoc item constraints, array lengths, and const param
defaults.
- Some `ast::AnonConst`s now have their `DefId`s created in
rustc_ast_lowering rather than `DefCollector`. This is because in some
cases they will end up becoming a `ConstArgKind::Path` instead, which
has no `DefId`. We have to solve this in a hacky way where we guess
whether the `AnonConst` could end up as a path const since we can't
know for sure until after name resolution (`N` could refer to a free
const or a nullary struct). If it has no chance as being a const
param, then we create a `DefId` in `DefCollector` -- otherwise we
decide during ast_lowering. This will have to be updated once all path
consts use `ConstArgKind::Path`.
- We explicitly use `ConstArgHasType` for array lengths, rather than
implicitly relying on anon const type feeding -- this is due to the
addition of `ConstArgKind::Path`.
- Some tests have their outputs changed, but the changes are for the
most part minor (including removing duplicate or almost-duplicate
errors). One test now ICEs, but it is for an incomplete, unstable
feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.
### Followup items post-merge
- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
instead (do this in rustc_resolve). Then remove the special-casing from
`rustc_ast_lowering`, so that all params will automatically be lowered as
`ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
trying it in crater
r? `@BoxyUwU`
