compiletest: Don't panic on unknown JSON-like output lines
The `json::extract_rendered` function is called for both compiler output and non-compiler output, so it's inappropriate to panic just because a line starting with `{` didn't contain a compiler output message.
It is called from two places: when checking the output of a `ui` test process, and when printing the output of an arbitrary non-passing `ProcRes`. So unfortunately there's currently no easy way to know for sure whether it is seeing compiler output or not. Fortunately, neither call site appears to be relying on this panic; it's just an overzealous internal check.
Fixes#126373.
Fix blessing of rmake tests
Fixes#129038.
When running in `--bless` mode, we now set the value of `RUSTC_BLESS_TEST` to the current test's source directory. This allows the diff helper in `run_make_support` to find the original snapshot file in the source directory and bless that, instead of unhelpfully blessing the temporary copy in `build`.
r? `@jieyouxu`
miri: make vtable addresses not globally unique
Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.
To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
Fix codegen-units tests that were disabled 8 years ago
I don't know if any of these tests still have value. They were disabled by https://github.com/rust-lang/rust/pull/33890, and we've survived without them for a while. But considering how small this test suite is, maybe it's worth having them.
I also had to add some normalization to the codegen-units tests output. I think the fact that I had to add some underscores how poor our test coverage is.
Apply "polymorphization at home" to RawVec
The idea here is to move all the logic in RawVec into functions with explicit size and alignment parameters. This should eliminate all the fussing about how tweaking RawVec code produces large swings in compile times.
This uncovered https://github.com/rust-lang/rust-clippy/issues/12979, so I've modified the relevant test in a way that tries to preserve the spirit of the test without tripping the ICE.
Link `std` statically in `rustc_driver`
This makes `rustc_driver` statically link to `std`. This is done by not passing `-C prefer-dynamic` when building `rustc_driver`. However building `rustc-main` won't work currently as it tries to dynamically link to both `rustc_driver` and `std` resulting in a crate graph with `std` duplicated. To fix that new command line option `-Z prefer_deps_of_dynamic` is added which prevents linking to a dylib if there's a static variant of it already statically linked into another dylib dependency.
The main motivation for this change is to enable `#[global_allocator]` to be used in `rustc_driver` allowing overriding the allocator used in rustc on all platforms.
---
Instead of adding `-Z prefer_deps_of_dynamic`, this PR is changed to crate opt-in to the linking change via the `rustc_private` feature instead, as that would be typically needed to link to `rustc_driver` anyway.
---
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: i686-mingw
try-job: dist-x86_64-msvc
try-job: aarch64-gnu
Promote aarch64-apple-darwin to Tier 1
This promotes aarch64-apple-darwin to Tier 1 status as per rust-lang/rfcs#3671 and tracking issue #73908. Not sure what else is necessary for this to impement the aforementioned RFC, however I figured I'd try. I did read in previous issues and PRs that the necessary infrastructure was already in place for the aarch64-apple-darwin target, and the RFC mentions the same. So this should be all thats necessary in order for the target to be promoted.
This is a recreation of my previous PR because I accidentally did an incorrect git rebase which caused unnecessary changes to various commit SHAs. So this PR is a recreation of my previous PR without said stumble. My bad.
Miscellaneous improvements to struct tail normalization
1. Make checks for foreign tails more accurate by normalizing the struct tail. I didn't write a test for this one.
2. Normalize when computing struct tail for `offset_of` for slice/str. This fixes the new solver only.
3. Normalizing when computing tails for disaligned reference check. This fixes both solvers.
r? lcnr
Rollup of 8 pull requests
Successful merges:
- #128640 (rwlock: disable 'frob' test in Miri on macOS)
- #128791 (Don't implement `AsyncFn` for `FnDef`/`FnPtr` that wouldnt implement `Fn`)
- #128806 (Split `ColorConfig` off of `HumanReadableErrorType`)
- #128818 (std float tests: special-case Miri in feature detection)
- #128834 (rustdoc: strip unreachable modules)
- #128836 (rustdoc-json: add a test for impls on private & hidden types)
- #128837 (Clippy subtree update)
- #128851 (Add comment that bors did not see pushed before it merged)
r? `@ghost`
`@rustbot` modify labels: rollup
Change generate-copyright to generate HTML, with cargo dependencies included
`x.py run generate-copyright` now produces `build/COPYRIGHT.html`. This includes a new format for in-tree dependencies, and also adds out-of-tree cargo dependencies.
After consulting expert opinion, I have elected to include every top-level:
* `*NOTICE*`
* `*AUTHOR*`
* `*LICENSE*`
* `*LICENCE*`, and
* `*COPYRIGHT*` file I can find - case-insensitive.
This is because the cargo package metadata's `author` field is not a list of copyright holders and does not meet the requirements of the Apache-2.0 license (which says you must include a NOTICE file with the binary if one was supplied by the author) nor the MIT license (which says you must include 'the above copyright notice').
I believe it would be appropriate to include this file with every Rust release, in order to do an even better job of appropriately recognising the efforts of the authors of the first-party and third-party libraries we are using here.
The output includes something like 524 copies of the Apache-2.0 text because they are not all identical. I think I count about 50 different variations by shasum - some differ in whitespace, while some have the boilerplate block at the bottom erroneously modified (don't modify the copy in the license, modify the copy you paste into your own source code!). Running `gzip` on the HTML file largely makes this problem go away, and the average browser is far happier with a ~6 MiB HTML file than the average Markdown viewer is with a ~6 MiB markdown file. But, if someone wants to, do they could submit a follow-up which de-dups the license text files and adds back-links to earlier identical copies (for some value of 'identical copy').
```console
$ xpy run generate-copyright
$ cd build
$ gzip -c COPYRIGHT.html > COPYRIGHT.gz
$ xz -c COPYRIGHT.html > COPYRIGHT.xz
$ ls -lh COPYRIGHT.*
-rw-r--r-- 1 jonathan staff 241K 29 Jul 17:19 COPYRIGHT.gz
-rw-r--r--@ 1 jonathan staff 6.6M 29 Jul 11:30 COPYRIGHT.html
-rw-r--r-- 1 jonathan staff 59K 29 Jul 17:19 COPYRIGHT.xz
```
Here's an example [COPYRIGHT.gz](https://github.com/user-attachments/files/16416147/COPYRIGHT.gz).
Add tests to ensure MTE tags are preserved across FFI boundaries
Added run-make tests to verify that, between a Rust-C FFI boundary in both directions, any MTE tags included in a pointer are preserved for the following pointer types, as well as any information stored using TBI:
- int
- float
- string
- function
try-job: aarch64-gnu
Migrate `pgo-gen-lto` `run-make` test 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).
This one is so easy, I'm surprised I missed it.
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
Migrate `simd-ffi` `run-make` test 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).
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-17
Migrate `cross-lang-lto-upstream-rlibs`, `long-linker-command-lines` and `long-linker-command-lines-cmd-exe` `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).
The `long-linker` tests are certainly doing something... interesting - they summon `rustc` calls with obscene quantities of arguments and check that this is appropriately handled. I removed the `RUSTC_ORIGINAL` magic - it's equivalent to `RUSTC` in `tools.mk`, so what is the purpose? Making it so the massive pile of flags doesn't modify rustc itself and start leaking into other tests? Tell me what you think.
Please try:
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw
try-job: i686-mingw
try-job: aarch64-apple
try-job: test-various
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-llvm-17
Update cargo
3 commits in fa646583675d7c140482bd906145c71b7fb4fc2b..94977cb1fab003d45eb5bb108cb5e2fa0149672a
2024-08-02 16:08:06 +0000 to 2024-08-06 21:42:10 +0000
- Don't specify the depedency name in the `cargo add` inferred name test (rust-lang/cargo#14357)
- Fix renamed disallowed cfg lint name (rust-lang/cargo#14352)
- fix(build-std): remove hack on creating virtual std workspace (rust-lang/cargo#14358)
r? ghost
run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`
The common thing between these two tests is to use `#[link(..., kind="static")]` so that it doesn't try to do a DLL import.
`zero-extend-abi-param-passing` also needs to have an optimized static library but there's only helper function for a non-optimized version. Rather than copy/pasting the code (and adding the optimization flag) I reused the same code so that it more easily be kept in sync.
try-job: i686-msvc
try-job: x86_64-msvc
Migrate `raw-dylib-alt-calling-convention`, `raw-dylib-c` and `redundant-libs` `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).
Please try:
// try-job: x86_64-msvc
// try-job: x86_64-mingw
// try-job: i686-msvc
try-job: x86_64-gnu-llvm-17
try-job: aarch64-apple
interpret: refactor function call handling to be better-abstracted
Add a new function `init_stack_frame` that pushes a stack frame and passes the arguments, and use that basically everywhere that the raw underlying `push_stack_frame` used to be called. This splits the previous monster function `eval_fn_call` into two parts: figuring out the MIR to call and the arguments to pass, and then actually setting up the stack frame.
Also re-organize the files a bit:
- The previous `terminator.rs` is split into a new `call.rs` with all the argument-passing logic, and the rest goes into `step.rs` where the other main dispatcher functions already live (in particular, `eval_statement`).
- All the stack frame handling from `eval_context.rs` is moved to a new `stack.rs`.
Pass the right `ParamEnv` to `might_permit_raw_init_strict`
Fixes#119620
`might_permit_raw_init_strict` currently passes an empty `ParamEnv` to the `InterpCx`, instead of the actual `ParamEnv` that was passed in to `check_validity_requirement` at callsite.
This leads to ICEs such as the linked issue where for `UnsafeCell<*mut T>` we initially get the layout with the right `ParamEnv` (which suceeds because it can prove that `T: Sized` and therefore `UnsafeCell<*mut T>` has a known layout) but then do the rest with an empty `ParamEnv` where `T: Sized` is not known to hold so getting the layout for `*mut T` later fails.
This runs into an assertion in other layout code where it's making the (valid) assumption that, when we already have a layout for a struct (`UnsafeCell<*mut T>`), getting the layout of one of its fields (`*mut T`) should also succeed, which wasn't the case here due to using the wrong `ParamEnv`.
So, this PR changes it to just use the same `ParamEnv` all the way throughout.
