compiletest: Fix `--exact` test filtering
This fix only changes the behavior when using `--exact` test filtering, which
was quite broken. Before this fix, the following runs 0 tests:
$ ./x test tests/run-make/crate-loading -- --exact
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 431 filtered out; finished in 24.95µs
With the fix the desired test is run:
$ ./x test tests/run-make/crate-loading -- --exact
running 1 tests
test [run-make] tests/run-make/crate-loading ... ok
Without `--exact` the set of run tests is unchanged. This still runs "too many" (cc rust-lang/rust#134341) tests
$ ./x test tests/run-make/crate-loading
running 3 tests
test [run-make] tests/run-make/crate-loading-crate-depends-on-itself ... ok
test [run-make] tests/run-make/crate-loading-multiple-candidates ... ok
test [run-make] tests/run-make/crate-loading ... ok
This still runs the one and only right test
$ ./x test tests/ui/lint/unused/unused-allocation.rs
running 1 tests
test [ui] tests/ui/lint/unused/unused-allocation.rs ... ok
### Notes
- I have not verified this on Windows which treats paths differently (but I see no reason why it should not work since my code should be platform agnostic).
Improve `core::ptr` coverage
This PR improves the `core::ptr` coverage by adding a new test to `coretests` for the `<*const T>::is_aligned_to` method.
r? libs
Tidy dependency checks cleanups + QoL
- Refactors the list of workspaces into a documented struct
- Provide accurate line info in 'Go to ..... for the list' message
- Print crate name on dependency issue (i.e. `dependency for rustc-main` instead of `dependency for .`
Remove `div_rem` from `core::num::bignum`
This fixes very old fixme that sounds like this
```
Stupid slow base-2 long division taken from
https://en.wikipedia.org/wiki/Division_algorithm
FIXME use a greater base ($ty) for the long division.
```
By deleting this method since it was never used
Move more early buffered lints to dyn lint diagnostics
Follow-up to rust-lang/rust#145747.
Presently, it's unclear to me if it's possible to migrate all variants to dyn lint diagnostics without regressing performance because for some early lints `decorate_builtin_lint` performs a bit more work (past PR rust-lang/rust#124417 has shown that eagerly decorating early lints is incredibly heavy and we had to revert back to lazily decorating in rust-lang/rust#125410). Let's see how this fares once I tackle the more 'risky' variants.
cc `@joshtriplett` (you can immediately unsubscribe again, I just want to prevent duplicate efforts).
document `core::ffi::VaArgSafe`
tracking issue: https://github.com/rust-lang/rust/issues/44930
A modification of https://github.com/rust-lang/rust/pull/146454, keeping just the documentation changes, but not unsealing the trait.
Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types.
This PR also adds some various other tests for edge cases of c-variadic:
- the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions.
- naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported
- guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it.
r? `@workingjubilee`
Update the arm-* and aarch64-* platform docs.
This PR updates some of the arm*-unknown-none target docs, and adds some missing target pages.
## aarch64-none-elf and aarch64-none-elf-softfloat
The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and a target page is added. Links are added to the EDWG's support crates for this target.
## armv7a-none-eabi and armv7a-none-eabihf
The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and a target page is added. Links are added to the EDWG's support crates for this target.
## armv7r-none-eabi and armv7r-none-eabihf
The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and the target page is split from the Big Endian versions. Links are added to the EDWG's support crates for this target.
## armebv7r-none-eabi and armveb7r-none-eabihf
The target page is split from the Little Endian versions. No change in maintainers.
I have agreement to add EDWG/T-Arm as maintainers, which was voted upon in [their repo](https://github.com/rust-embedded/wg/issues/851).
Some hygiene doc improvements
Improve some doc comments around SyntaxContext, outer_expn and friends.
Based on discussion at https://github.com/rust-lang/rust/pull/146100.
r? petrochenkov
Document `become` keyword
The feature is not yet implemented, so I'm not sure if we should merge this _right away_, promoting an incomplete feature is probably not the best idea. But the docs can be reviewed while the implementation work is being done.
update fixme in compare_method_predicate_entailment resulting from review of EII
r? `@lcnr`
Just the comment update separately from https://github.com/rust-lang/rust/pull/146348/files since it doesn't really belong in that PR. Should be trivial
This is important to note, as it affects how easy it is to build a
binary, and that `#![no_std]` is mandatory.
A different PR should probably add this to all the other platform pages.
Make `AssocItem` aware of its impl kind
The general goal is to have fewer query dependencies by making `AssocItem` aware of its parent impl kind (inherent vs. trait) without having to query the parent def_kind.
See individual commits.
This fix only changes the behavior when using `--exact` test filtering,
which was quite broken. Before this fix, the following runs 0 tests:
$ ./x test tests/run-make/crate-loading -- --exact
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 431 filtered out; finished in 24.95µs
With the fix the desired test is run:
$ ./x test tests/run-make/crate-loading -- --exact
running 1 tests
test [run-make] tests/run-make/crate-loading ... ok
Without `--exact` the set of run tests is unchanged. This still runs
"too many" tests
$ ./x test tests/run-make/crate-loading
running 3 tests
test [run-make] tests/run-make/crate-loading-crate-depends-on-itself ... ok
test [run-make] tests/run-make/crate-loading-multiple-candidates ... ok
test [run-make] tests/run-make/crate-loading ... ok
This still runs the one and only right test:
$ ./x test tests/ui/lint/unused/unused-allocation.rs
running 1 tests
test [ui] tests/ui/lint/unused/unused-allocation.rs ... ok
bootstrap: rustdoc-js tests can now be filtered by js files
Before, a command like `./x test tests/rustdoc-js/path-ordering.js` would succeed, but run no tests, since the names of the tests are based on the `.rs` file. This is a bit confusing, as the `rustdoc-js-std` test suite only has `.js` files, and thus those are the files you filter on. Now, `./x test tests/rustdoc-js/path-ordering.js` will be treated as an alias for `./x test tests/rustdoc-js/path-ordering.rs`. This is fairly simple as each `rustdoc-js` test has 2 files, 1 js file and one rust file, each with an identical base filename, so all we need to do is swap the extension.
r? `@Kobzol`
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Add --print target-spec-json-schema
This schema is helpful for people writing custom target spec JSON. It can provide autocomplete in the editor, and also serves as documentation when there are documentation comments on the structs, as `schemars` will put them in the schema.
I was motivated to do this because I saw someone write their own version of this schema by hand, so demand for this clearly exists. It's not a lot of effort to implement, so I thought it would make sense.
MCP: https://github.com/rust-lang/compiler-team/issues/905
I think it would also be useful to put this in the sysroot in `etc` so people can link it directly in their editors.
I would have loved to add a test that validates the JSON schema against the spec JSON of every builtin target, but I don't want to do it as the JSON schema validation crates have incredible amounts of dependencies because JSON schema supports a ton of random features. I don't want to add that, even as a dev dependency.
