| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#141703 (Structurally normalize types as needed in `projection_ty_core`)
- rust-lang/rust#141719 (Add tls_model for cygwin and enable has_thread_local)
- rust-lang/rust#141736 (resolve stage0 sysroot from rustc)
- rust-lang/rust#141746 (Rework `#[doc(cfg(..))]` checks as distinct pass in rustdoc)
- rust-lang/rust#141749 (Remove RUSTC_RETRY_LINKER_ON_SEGFAULT hack)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Noratrieb:RUSTC_ACTUALLY_DO_NOT_RETRY_LINKER_ON_SEGFAULT, r=petrochenkov
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
|
|
Rework `#[doc(cfg(..))]` checks as distinct pass in rustdoc
This PR reworks how rustdoc calls `rustc_attr_parsing::cfg_matches` to be in a separate pass, instead of being wired-up in a ad-hoc way, which is causing problems in https://github.com/rust-lang/rust/pull/138907#issuecomment-2920026627.
This un-does most part of https://github.com/rust-lang/rust/pull/140894, but the result is IMO much cleaner, easier to reason about, and most importantly no longer interfears with rust-lang/rust#138907.
r? `@GuillaumeGomez`
|
|
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
|
|
rustdoc: cleanups relating to allocations
These commits generally clean up the code a bit and also reduce allocation rates a bit.
r? `@camelid`
|
|
rustdoc: display doc(cfg(false)) properly
before we had an extra 'on' that was
ungramatical.
fixes https://github.com/rust-lang/rust/issues/138112
this is what it looks like now:
|
|
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
Fixes rust-lang/rust#127911
Fixes rust-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
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#137574 (Make `std/src/num` mirror `core/src/num`)
- rust-lang/rust#141384 (Enable review queue tracking)
- rust-lang/rust#141448 (A variety of improvements to the codegen backends)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
- rust-lang/rust#141676 (float: Disable `total_cmp` sNaN tests for `f16`)
- rust-lang/rust#141705 (Add eslint as part of `tidy` run)
- rust-lang/rust#141715 (Add `loongarch64` with `d` feature to `f32::midpoint` fast path)
- rust-lang/rust#141723 (Provide secrets to try builds with new bors)
- rust-lang/rust#141728 (Fix false documentation of FnCtxt::diverges)
- rust-lang/rust#141729 (resolve target-libdir directly from rustc)
- rust-lang/rust#141732 (creader: Remove extraenous String::clone)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
|
|
before we had an extra 'on' that was
ungramatical.
fixes https://github.com/rust-lang/rust/issues/138112
|
|
|
|
Bump rustc-perf and update PGO crates
Updates rustc-perf to rust-lang/rustc-perf@8158f78f738715c060d230351623a7f7cc01bf97, and updates the crates.
r? `@Kobzol`
|
|
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 fix rust-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>
|
|
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.
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.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#138285 (Stabilize `repr128`)
- rust-lang/rust#139994 (add `CStr::display`)
- rust-lang/rust#141571 (coretests: extend and simplify float tests)
- rust-lang/rust#141656 (CI: Add cargo tests to aarch64-apple-darwin)
Failed merges:
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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
|
|
Stabilize `repr128`
## Stabilisation report
The `repr128` feature ([tracking issue](https://github.com/rust-lang/rust/issues/56071)) allows the use of `#[repr(u128)]` and `#[repr(i128)]` on enums in the same way that other primitive representations such as `#[repr(u64)]` can be used. For example:
```rust
#[repr(u128)]
enum Foo {
One = 1,
Two,
Big = u128::MAX,
}
#[repr(i128)]
enum Bar {
HasThing(u16) = 42,
HasSomethingElse(i64) = u64::MAX as i128 + 1,
HasNothing,
}
```
This is the final part of adding 128-bit integers to Rust ([RFC 1504](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in #49101 back in 2018.
From a design perspective, `#[repr(u128)]`/`#[repr(i128)]` function like `#[repr(u64)]`/`#[repr(i64)]` but for 128-bit integers instead of 64-bit integers. The only differences are:
- FFI safety: as `u128`/`i128` are not currently considered FFI safe, neither are `#[repr(u128)]`/`#[repr(i128)]` enums (I discovered this wasn't the case while drafting this stabilisation report, so I have submitted #138282 to fix this).
- Debug info: while none of the major debuggers currently support 128-bit integers, as of LLVM 20 `rustc` will emit valid debuginfo for both DWARF and PDB (PDB makes use of the same natvis that is also used for all enums with fields, whereas DWARF has native support).
Tests for `#[repr(u128)]`/`#[repr(i128)]` enums include:
- [ui/enum-discriminant/repr128.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values.
- [debuginfo/msvc-pretty-enums.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct.
- [run-make/repr128-dwarf](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct.
Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`.
Closes #56071
Closes https://github.com/rust-lang/reference/issues/1368
r? lang
```@rustbot``` label +I-lang-nominated +T-lang
|
|
rustbook: Bump versions of `onig` and `onig_sys`
This fixes the build on GCC 15.
|
|
replace TraitRef link memory.md
Hi, I fixed broken links in the documentation and replaced them with working ones.
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html - old link
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.TraitRef.html - new link
|
|
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`
|
|
ci: verify that codebuild jobs use ghcr.io
|
|
Use `builtin_index` instead of hand-rolling it
Just using the dedicated method more
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#140369 (Add data_ptr method to Mutex and RwLock)
- rust-lang/rust#140697 (Split `autodiff` into `autodiff_forward` and `autodiff_reverse`)
- rust-lang/rust#141404 (Improve intrinsic handling in cg_ssa)
- rust-lang/rust#141411 (rustdoc: linking to a local proc macro no longer warns)
- rust-lang/rust#141548 (consider glob imports in cfg suggestion)
- rust-lang/rust#141627 (Drop-build cleanups)
- rust-lang/rust#141670 (Fix ICE in tokenstream with contracts from parser recovery)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=GuillaumeGomez
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.
|
|
ci: move tests from x86_64-gnu-llvm-19 job to aarch64
|
|
|
|
This fixes the build on GCC 15
|
|
|
|
|
|
feat: Desugar assist for `let pat = expr?;` -> `let else`
|
|
|
|
ci: move dist-x86_64-linux job to codebuild
|
|
fix: Handle included files better in IDE layer
|
|
fix: Fix inference of `AsyncFnX` return type
|
