Remove RUSTC_RETRY_LINKER_ON_SEGFAULT hack
It looks like this was added in rust-lang/rust#40422 6 years ago because of issues with the MacOS linker. MacOS got a new linker in the meantime, so that should probably be resolved now. Hopefully.
r? petrochenkov
resolve stage0 sysroot from rustc
Similar to https://github.com/rust-lang/rust/pull/141729, instead of manually navigating directories based on stage0 rustc, use `--print sysroot` to get the sysroot directly. This also works when using the bootstrap `rustc` shim.
r? Kobzol
Add tls_model for cygwin and enable has_thread_local
I've also tried to set `has_thread_local` to `true` and found it works actually. Why do we still implement our own `thread_local` instead of delegating all of them to LLVM?
cc: `@jeremyd2019`
Structurally normalize types as needed in `projection_ty_core`
Introduce a `structurally_normalize` callback to `projection_ty_core`, and then use it before we match on the ty kind in `projection_ty_core`.
Previously we were only structurally normalizing the return type of the `handle_field` struct, but if we were to (e.g.) apply a deref projection to that type, then the resulting type is not guaranteed to be structurally normalized and any subsequent projections applied would ICE.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/221
I'll leave a few comments inline to explain the changes.
r? lcnr
---
Also fixesrust-lang/rust#141708
`is_trait_method` is not even used in this codeblock, whereas
`implements_trait` is used but not imported
(not sure if this is _actually_ a "changelog: none", since the
documentation is at least contributor-facing)
changelog: none
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#133823 (Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion)
- rust-lang/rust#141004 (Report text_direction_codepoint_in_literal when parsing)
- rust-lang/rust#141407 (Refactor the two-phase check for impls and impl items)
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141507 (atomic_load intrinsic: use const generic parameter for ordering)
- rust-lang/rust#141538 (implement `va_arg` for x86_64 systemv)
- rust-lang/rust#141669 (float: Replace some approximate assertions with exact)
- rust-lang/rust#141747 (rustdoc: display doc(cfg(false)) properly)
r? `@ghost`
`@rustbot` modify labels: rollup
float: Replace some approximate assertions with exact
As was mentioned at [1], we currently use `assert_approx_eq` for testing
some math functions that guarantee exact results. Replace approximate
assertions with exact ones for the following:
* `ceil`
* `floor`
* `fract`
* `from_bits`
* `mul_add`
* `round_ties_even`
* `round`
* `trunc`
This likely wasn't done in the past to avoid writing out exact decimals
that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004),
but ensuring our results are accurate seems more important here.
[1]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
The first commit is a small bit of macro cleanup.
try-job: aarch64-gnu
try-job: x86_64-gnu-aux
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`
`visit_clobber` is not really useful except for one niche purpose
involving generic code. We should just use the replace logic where we
can.
Refactor the two-phase check for impls and impl items
Refactor the two-phase dead code check to make the logic clearer and simpler:
1. adding assoc fn and impl into `unsolved_items` directly during the initial construction of the worklist
2. converge the logic of checking whether assoc fn and impl are used to `item_should_be_checked`, and the item is considered used only when its corresponding trait and Self adt are used
This PR only refactors as much as possible to avoid affecting the original functions. However, due to the adjustment of the order of checks, the test results are slightly different, but overall, there is no regression problem
Fixesrust-lang/rust#127911Fixesrust-lang/rust#128839
Extracted from https://github.com/rust-lang/rust/pull/128637.
r? petrochenkov
try-job: dist-aarch64-linux
Report text_direction_codepoint_in_literal when parsing
The lint is now reported in code that gets removed/modified/duplicated by macro expansion, and spans are more accurate so we don't get ICEs from trying to split a span in the middle of a character.
This removes support for lint level attributes for `text_direction_codepoint_in_literal` except at the crate level, I don't think that there's an easy way around this when the lint can be reported on code that's removed by `cfg` or that is only in the input of a macro.
Fixes#140281
Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion
In rust-lang/rust#138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fixrust-lang/rust#56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused `extern crate`
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
|
```
r? `@petrochenkov`
try-job: x86_64-gnu-aux
We don't actually need this for now, but eventually it would be nice to
run icount benchmarks on multiple targets. Start tagging artifact names
with the architecture, and allow passing `--tag` to `ci-util.py` in
order to retrieve the correct one.
It looks like this was added 6 years ago because of issues with the
MacOS linker. MacOS got a new linker in the meantime, so that should
probably be resolved now. Hopefully.
`assert_eq!` ignores the sign of zero, but for any tests involving zeros
we do care about this sign. Replace `assert_eq!` with `assert_biteq!`
everywhere possible for float tests to ensure we don't miss this.
`assert_biteq!` is also updated to check equality on non-NaNs, to catch
the unlikely case that bitwise equality works but our `==`
implementation is broken.
There is one notable output change: we were asserting that
`(-0.0).fract()` and `(-1.0).fract()` both return -0.0, but both
actually return +0.0.
As was mentioned at [1], we currently use `assert_approx_eq` for testing
some math functions that guarantee exact results. Replace approximate
assertions with exact ones for the following:
* `ceil`
* `floor`
* `fract`
* `from_bits`
* `mul_add`
* `round_ties_even`
* `round`
* `trunc`
This likely wasn't done in the past to avoid writing out exact decimals
that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004),
but ensuring our results are accurate seems more important here.
[1]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
