bootstrap: lower verbosity of cargo to one less than bootstrap's
the main thing this does is eliminate the "Fresh ..." output when `--verbose` is only passed once.
r? `@Kobzol`
improve internal bootstrap docs
Mainly focused on making it easier to figure out how tools get built without having to read the `bootstrap_tool!` macro, but also added some subdirs of `build/` to the readme.
compiletest: Make `./x test --test-args ...` work again
It accidentally broke with https://github.com/rust-lang/rust/pull/146501. The intention of that PR was to keep existing behavior if `--exact` is not used, but it had a bug. This PR fixes that bug.
compiletest: Enable new-output-capture by default
The new output-capture implementation was added in rust-lang/rust#146119, but was disabled by default and required opt-in.
Since then, I haven't encountered any problems in my own testing/usage, and I haven't heard any problem reports from other contributors who might have opted in.
It's unlikely that more opt-in testing will help, so the next step is to enable new-output-capture by default and see if anyone complains. (Hopefully nobody!)
If needed, the new default can be overridden (for now) by setting environment variable `COMPILETEST_NEW_OUTPUT_CAPTURE=off`. Please file an issue (or let me know) if anyone finds a reason to do this.
r? jieyouxu
llvm-wrapper: other cleanup
Cleanup few things around llvm-wrapper:
First commit removes unused macro, added back in https://github.com/rust-lang/rust/pull/31709 it was used in `LLVMRustHasFeature`; second removes unused function, third one removes `jsbackend` llvm component - this is looks like remnants of some removed backend?
interpret: fix overlapping aggregate initialization
This fixes the problem pointed out by ````@saethlin```` in https://github.com/rust-lang/rust/issues/146383#issuecomment-3273224645.
Also clarify when exactly current de-facto MIR semantics allow overlap of the LHS and RHS in an assignment.
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`
Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait.
r? `@BoxyUwU`
It accidentally broke with a48c8e337d1. The intention of that commit was
to keep existing behavior if `--exact` is not used, but it had a bug.
This commit fixes that bug.
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).
