linker: Report linker flavors incompatible with the current target
The linker flavor is checked for target compatibility even if linker is never used (e.g. we are producing a rlib).
If it causes trouble, we can move the check to `link.rs` so it will run if the linker (flavor) is actually used.
And also feature gate explicitly specifying linker flavors for tier 3 targets.
The next step is supporting all the internal linker flavors in user-visible interfaces (command line and json).
new lint: `missing_fields_in_debug`
Fixes#10429
This PR adds a new lint that looks for manual `Debug` implementations that do not "use" all of the fields.
This often happens when adding a new field to a struct.
It also acts as a style lint in case leaving out a field was intentional. In that case, it's preferred to use [`DebugStruct::finish_non_exhaustive`](https://doc.rust-lang.org/stable/std/fmt/struct.DebugStruct.html#method.finish_non_exhaustive), which indicates that there are more fields that were explicitly not shown.
```
changelog: [`missing_fields_in_debug`]: missing fields in manual `Debug` implementation
```
move some strings into consts, more tests
s/missing_field_in_debug/missing_fields_in_debug
dont trigger in macro expansions
make dogfood tests happy
minor cleanups
replace HashSet with FxHashSet
replace match_def_path with match_type
if_chain -> let chains, fix markdown, allow newtype pattern
fmt
consider string literal in `.field()` calls as used
don't intern defined symbol, remove mentions of 'debug_tuple'
special-case PD, account for field access through `Deref`
This makes it more clear that we're using stage 0 *to document* rustc, not that we're documenting
stage0 rustc itself.
It also fixes a bug in `msg_sysroot_tool` that would print `Docing`, and removes the `Debug` impl
for `Kind` to make sure it doesn't happen again.
Before:
```
Documenting stage0 compiler {rustc-main} (aarch64-apple-darwin)
```
After:
```
Documenting compiler {rustc-main} (stage0 -> stage1, aarch64-apple-darwin)
```
Before, cargo would error:
```
; git push
Running pre-push script /home/jyn/src/rust/x test tidy
Building bootstrap
Finished dev [unoptimized] target(s) in 0.02s
Build stage0 tool tidy (x86_64-unknown-linux-gnu)
error: the argument '--locked' cannot be used multiple times
Usage: cargo build [OPTIONS]
For more information, try '--help'.
Build completed unsuccessfully in 0:00:00
error: failed to push some refs to 'github.com:jyn514/rust.git'
```
Only rewrite valtree-constants to patterns and keep other constants opaque
Now that we can reliably fall back to comparing constants with `PartialEq::eq` to the match scrutinee, we can
1. eagerly try to convert constants to valtrees
2. then deeply convert the valtree to a pattern
3. if the to-valtree conversion failed, create an "opaque constant" pattern.
This PR specifically avoids any behavioral changes or major cleanups. What we can now do as follow ups is
* move the two remaining call sites to `destructure_mir_constant` off that query
* make valtree to pattern conversion infallible
* this needs to be done after careful analysis of the effects. There may be user visible changes from that.
based on https://github.com/rust-lang/rust/pull/111768
Remove lint name and category fields from the new lint issue form
changelog: none
Picking a name/category is something the implementers/reviewers tend to cover anyway, I think asking people to come up with it at the time of their suggestion is more of a barrier than it's worth
Inspired by the mention in #10849
We record inlining status for mono items in `MonoItems`, and then
transfer it to `InliningMap`, for later use in
`InliningMap::with_inlining_candidates`.
But we can just compute inlining status directly in
`InliningMap::with_inlining_candidates`, because the mono item is right
there. There's no need to compute it in advance.
This commit changes the code to do that, removing the need for
`MonoItems` and `InliningMap::inlines`. This does result in more calls
to `instantiation_mode` (one per static occurrence) but the performance
effect is negligible.
Rollup of 5 pull requests
Successful merges:
- #111772 (Fix linkage for large binaries on mips64 platforms)
- #111975 (Stop normalizing so many different prefixes)
- #111979 (Respect CARGOFLAGS in bootstrap.py)
- #112089 (Add `--warnings warn` flag to `x.py`)
- #112103 (Bootstrap update to 1.71 beta)
r? `@ghost`
`@rustbot` modify labels: rollup
python3 snippet used to fill $MIRIDIR variable returns native paths.
Down the line in `bench` subcommand this leads to benchmark setup
failure, preventing contributors from running benchmarks on Windows
hosts.
This commit replaces usage of native os.path module with pathlib, which
explicitly converts paths to Unix flavour.
Add `--warnings warn` flag to `x.py`
So that bootstrap itself can be built with warnings not being treated as errors.
Fixes: https://github.com/rust-lang/rust/issues/76805
r? ```@jyn514```
Respect CARGOFLAGS in bootstrap.py
This makes it possible to pass flags to bootstrap itself, for consistency with std/rustc: 04265621f9/src/bootstrap/builder.rs (L1446-L1447)
Like RUSTFLAGS, this doesn't support CARGOFLAGS_BOOTSTRAP: 6674dcda7a/src/bootstrap/bootstrap.py (L883-L884)
I found this useful recently when I wanted to pass `-Zsparse-registry` to an old checkout of the compiler from before it was stabilized in cargo.
Stop normalizing so many different prefixes
Previously, we would normalize *all* of
- the absolute path to the repository checkout
- the /rustc/$sha for stage1 (if `remap-debuginfo` was enabled)
- the /rustc/$sha for download-rustc
- the sysroot for download-rustc
Now, we consistently only normalize /rustc/FAKE_PREFIX. Not only is this much simpler, but it also avoids ongoing maintenance for download-rustc and makes it much less likely that tests break by accident.
- Change `tests/ui/track-diagnostics/track6.rs` to use a relative path instead of an absolute one. I am not actually sure why `track_caller` works here, but it does seem to work 🤷
- Pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` to all suites, not just UI. In particular, mir-opt tests emit /rustc/ paths in their output.
r? ```@cjgillot``` since you reviewed https://github.com/rust-lang/rust/pull/110699 - this is the test that it doesn't regress :)
Fix linkage for large binaries on mips64 platforms
This pull request fixes the linkage for large binaries on mips64 platforms by enabling the `xgot` feature in LLVM.
It is well understood that the generated binary will gain a hefty performance penalty where the external symbol jumps now cost at least three instructions each.
Also, this pull request does not address the same issue on the mips32 counterparts (due to being unable to test the changes thoroughly).
Should fix#52108
