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?
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
resolve target-libdir directly from rustc
Leaving stage0 target-libdir resolution to rustc. This should also fix the issue with hard-coding `$sysroot/lib` which fails on systems that use `$sysroot/lib64` or `$sysroot/lib32`.
Haven't tested, but should fixrust-lang/rust#141722
Add eslint as part of `tidy` run
Rustdoc uses `eslint` to run lints on the JS files. Currently you need to run it by hand since it's not part of any `x.py` command. This PR makes it part of `test tidy`. However, to prevent having all rust developers to install `npm` and `eslint`, I made it optional: if `eslint` is not installed, then the check is simply skipped (but will tell that it is being skipped).
The second commit removes the manual checks from the docker file since `eslint` is run as part of tidy.
cc `@lolbinarycat,` [#t-rustdoc > eslint seems to only be run in CI](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/eslint.20seems.20to.20only.20be.20run.20in.20CI/with/520761477)
Leaving stage0 target-libdir resolution to rustc. This should also fix the issue with
hard-coding `$sysroot/lib` which fails on systems that use `$sysroot/lib64` or `$sysroot/lib32`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Do not get proc_macro from the sysroot in rustc
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
CI: Add cargo tests to aarch64-apple-darwin
This adds running of cargo's tests to the aarch64-apple-darwin job. The reason for this is that tier-1 targets are ostensibly supposed to run tests for host tools, but we are not doing that here. We do have fairly good coverage in Cargo's CI, but we don't cover the beta or stable branches here. I think it would be good to have a fallback here.
I think this should only add about 7 minutes of CI time, but I have not measured it. The current job is about 1.5 hours.
In summary of the tier-1 targets:
| Target | rust-lang/cargo | rust-lang/rust |
|--------|-----------------|----------------|
| aarch64-apple-darwin | stable/nightly | ❌ (this PR) |
| aarch64-unknown-linux-gnu | stable/nightly | ✓ |
| x86_64-apple-darwin | nightly | ❌ |
| x86_64-pc-windows-gnu | nightly | ❌ |
| x86_64-pc-windows-msvc | stable | ✓ |
| x86_64-unknown-linux-gnu | stable/beta/nightly | ✓ |
| i686-pc-windows-msvc | ❌ | ❌ |
| i686-unknown-linux-gnu | ❌ | ❌ |
try-job: aarch64-apple
Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
r? `@fee1-dead`
rustdoc: linking to a local proc macro no longer warns
fixes https://github.com/rust-lang/rust/issues/91274
tried to keep the fix general in case we ever have any other kind of item that occupies
multiple namespaces simultaniously.
This does not fully fix things, but it introduces a function that can be used to fix occurences.
When using `to_def` functionality, the input node needs to come from the macro expanded include, not the real file that was included.
This does unfortunately add more caller burden, but there is not really a way around it.
Disable libunwind cross-architecture unwinding
Building with _LIBUNWIND_IS_NATIVE_ONLY disables code for cross-architecture unwinding It also enables some additional code that handles PAC-specific unwind info it helps compiling with the -mbranch-protection=pac or -mbranch-protection=standard flags
This fixes build with clang/musl on aarch64
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
`concat_idents!` was deprecated in [1] and will be removed in the near
future. rust-analyzer's support is independent of rustc's, so drop RA
support now to make syncing easier.
[1]: https://github.com/rust-lang/rust/pull/137653
Matthias Krüger