This function can cause false negatives if used incorrectly
(usually "do any of the doc fragments come from a macro" is
the wrong question to ask), and thus it is unused.
Rename `tests/{assembly,codegen}` into `tests/{assembly,codegen}-llvm` and ignore these testsuites if configured backend doesn't match
Follow-up of https://github.com/rust-lang/rust/pull/144125.
This PR changes `compiletest` so that `asm` tests are only run if they match the current codegen backend. To better reflect it, I renamed the `tests/ui/asm` folder into `tests/ui/asm-llvm`. Like that, we can add new asm tests for other backends if we want without needing to add extra code to `compiletest`.
Next step will be to use the new code annotations added in rust-lang/rust#144125 to ignore ui tests failing in cg_gcc until it's fixed on our side.
cc `@antoyo` `@oli-obk`
r? `@Kobzol`
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#142454 (Add modern AVR mcus like avr128db28 and attiny3224)
- rust-lang/rust#142924 (tidy: move rustdoc js stuff into a tidy extra check)
- rust-lang/rust#143373 (Unquerify maybe_unused_trait_imports.)
- rust-lang/rust#144082 (tests: cover more `exported_private_dependencies` cases)
- rust-lang/rust#144126 (Fix empty target_config in apply_rust_config bootstrap)
- rust-lang/rust#144164 ( opt-dist: add an option for setting path to stage0 root)
- rust-lang/rust#144265 (Dont ICE on copy error being suppressed due to overflow)
r? `@ghost`
`@rustbot` modify labels: rollup
flt2dec: replace for loop by iter_mut
Perf is explored in https://github.com/rust-lang/rust/issues/144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
opt-dist: add an option for setting path to stage0 root
in MSYS2 we have problems with stage0 for *-gnullvm hosts because prebuilt dist tarballs will be
available starting from 1.90.0-beta. also this change helps to match bootstrap.toml config
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
Fix empty target_config in apply_rust_config bootstrap
This PR fixes the issue of an empty target_config in apply_rust_config, which was caused by the ordering of TOML config parsing. This was inadvertently introduced during the last config refactor. The test and the corresponding configuration order have been corrected in this PR.
r? ```@Kobzol```
tests: cover more `exported_private_dependencies` cases
This PR adds tests for all missing cases from rust-lang/rust#71043 and some on top of that. I believe with this, that issue can be closed.
Some of the lints can be improved, e.g. `provided_impl_trait` and `impl From<PublicWithStdImpl> for OtherType` lint twice.
cc ```@epage``` in case you want to double check I didn't miss anything.
tidy: move rustdoc js stuff into a tidy extra check
Most of these were factored out of CI scripts, but `eslint` in particular was previously implemented with its own special cased logic.
A new option has been added to bootstrap, `build.tidy-extra-checks`, which serves as a default value for the `--extra-checks` flag. This is mostly for the benefit of rustdoc js maintainers, but should also help bootstrap py maintainers.
Additionally, `--extra-checks=cpp` has been documented.
I'm not super happy with how long the extra check names are in comparison to the others (in particular `typecheck`), but I couldn't think of anything better (I didn't want to name it `tsc` on the off chance we want to switch to a different typechecking engine in the future).
It would be nice to convert the extra checks arg into a proper enum, both for warning on unknown values and to provide better shell completion.
r? ```@GuillaumeGomez```
Fixes: https://github.com/rust-lang/rust/issues/144093
Rather than adding `get_unused_rule` to the `TTMacroExpander` trait, put
it on the concrete `MacroRulesMacroExpander`, and downcast to that type
via `Any` in order to call it.
Suggested-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
The previous manual parsing of `serde_json::Value` was a lot of
complicated code and extremely error-prone. It was full of janky
behavior like sometimes ignoring type errors, sometimes erroring for
type errors, sometimes warning for type errors, and sometimes just
ICEing for type errors (the icing on the top).
Additionally, many of the error messages about allowed values were out
of date because they were in a completely different place than the
FromStr impls. Overall, the system caused confusion for users.
I also found the old deserialization code annoying to read. Whenever a
`key!` invocation was found, one had to first look for the right macro
arm, and no go to definition could help.
This PR replaces all this manual parsing with a 2-step process involving
serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct
is a 1:1 representation of the spec JSON. It already parses all the
enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`.
The reason for this two-step process instead of just serializing into a
`Target` is because of a few reasons
1. There are a few transformations performed between the two formats
2. The default logic is implemented this way. Otherwise all the default
field values would have to be spelled out again, which is
suboptimal. With this logic, they fall out naturally, because
everything in the json struct is an `Option`.
Overall, the mapping is pretty simple, with the vast majority of fields
just doing a 1:1 mapping that is captured by two macros. I have
deliberately avoided making the macros generic to keep them simple.
All the `FromStr` impls now have the error message right inside them,
which increases the chance of it being up to date. Some "`from_str`"
impls were turned into proper `FromStr` impls to support this.
The new code is much less involved, delegating all the JSON parsing
logic to serde, without any manual type matching.
This change introduces a few breaking changes for consumers. While it is
possible to use this format on stable, it is very much subject to
change, so breaking changes are expected. The hope is also that because
of the way stricter behavior, breaking changes are easier to deal with,
as they come with clearer error messages.
1. Invalid types now always error, everywhere. Previously, they would
sometimes error, and sometimes just be ignored (which meant the users
JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning
on unused fields, which was done previously. Serde doesn't make it
easy to get such warning behavior, which was the primary reason that
this now changed. But I think error behavior is very reasonable too.
If someone has random stale fields in their JSON, it is likely
because these fields did something at some point but no longer do,
and the user likely wants to be informed of this so they can figure
out what to do.
This is also relevant for the future. If we remove a field but
someone has it set, it probably makes sense for them to take a look
whether they need this and should look for alternatives, or whether
they can just delete it. Overall, the JSON is made more explicit.
This is the only expected breakage, but there could also be small
breakage from small mistakes. All targets roundtrip though, so it can't
be anything too major.
opt-dist: make `artifact-dir` an absolute path for `opt-dist local`
...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some intermediate steps fail due to path being relative to an active directory
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
Don't use another main test file as auxiliary
In this case, the exact extern crate isn't very important, it just needs to not be another main test file.
This is part of the changes needed to address the spurious failures from a main test `../removing-extern-crate.rs` being both an auxiliary and a main test file, causing fs races due to multiple `rustc` processes in multiple test threads trying to build the main test file both as a main test and also as an auxiliary at around the same time.
Part 1 of rust-lang/rust#144237.
r? ``@RalfJung`` (or compiler)
