| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Co-authored-by: Travis Cross <tc@traviscross.com>
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#141554 (Improve documentation for codegen options)
- rust-lang/rust#141817 (rustc_llvm: add Windows system libs only when cross-compiling from Wi…)
- rust-lang/rust#141843 (Add `visit_id` to ast `Visitor`)
- rust-lang/rust#141881 (Subtree update of `rust-analyzer`)
- rust-lang/rust#141898 ([rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id)
- rust-lang/rust#141921 (Disable f64 minimum/maximum tests for arm 32)
- rust-lang/rust#141930 (Enable triagebot `[concern]` functionality)
- rust-lang/rust#141936 (Decouple "reporting in deps" from `FutureIncompatibilityReason`)
- rust-lang/rust#141949 (move `test-float-parse` tool into `src/tools` dir)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Decouple "reporting in deps" from `FutureIncompatibilityReason`
The reason should just be it -- the reason. It never felt right to me that it was also responsible for whatever we include the warning in cargo's reports.
It gets especially unruly if you want to add non-`FutureReleaseError*` warnings which are included in the reports.
I just added a field to `FutureIncompatibleInfo` to control whatever the diagnostic is included in the cargo's reports.
|
|
Add `visit_id` to ast `Visitor`
This helps with efforts to deduplicate the `MutVisitor` and the `Visitor` code. All users of `Visitor`'s methods that have extra `NodeId` as parameters really just want to visit the id on its own.
Also includes some methods deduplicated and cleaned up as a result of this change.
r? oli-obk
|
|
r=cuviper
rustc_llvm: add Windows system libs only when cross-compiling from Wi…
…ndows
This obviously doesn't work when cross-compiling from Linux.
Split out from: https://github.com/rust-lang/rust/pull/140772
Fixes the issue described at [#general > Problems while trying to cross compile rustc for windows](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/Problems.20while.20trying.20to.20cross.20compile.20rustc.20for.20windows/with/520508561)
|
|
|
|
Fix borrowck mentioning a name from an external macro we (deliberately) don't save
Most of the info is already in the title :shrug:
Closes rust-lang/rust#141764
|
|
Don't declare variables in `ExprKind::Let` in invalid positions
Handle `let` expressions in invalid positions specially during resolve in order to avoid making destructuring-assignment expressions that reference (invalid) variables that have not yet been delcared yet.
See further explanation in test and comment in the source.
Fixes rust-lang/rust#141844
|
|
Overhaul `UsePath`
It currently uses `SmallVec<[Res; 3]>` which is really weird. Details in the individual commits.
r? `@petrochenkov`
|
|
azhogin:azhogin/async-drop-unexpected-type-instead-of-drop-fn-fix, r=oli-obk
Async drop - type instead of async drop fn, fixes #140484
Fixes: rust-lang/rust#140484
Fixes: rust-lang/rust#140500
Fixes ICE, when type is provided in AsyncDrop trait instead of `async fn drop()`.
Fixes ICE, when async drop fn has wrong signature.
|
|
Warn when gold was used as the linker
gold has been deprecated recently and is known to behave incorrectly around Rust programs, including miscompiling `#[used(linker)]`. Tell people to switch to a different linker instead.
closes rust-lang/rust#141748
r? bjorn3
|
|
`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res`
results, one per namespace (type, value, or macro). `lower_import_res`
takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the
`SmallVec`. This is pretty weird. The input `PerNS` makes it clear which
`Res` belongs to which namespace, but the `SmallVec` throws that
information away.
And code that operates on the `SmallVec` tends to use iteration (or even
just grabbing the first entry!) without knowing which namespace the
`Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible
type to use here, because it can contain any number of elements (even
though it's optimized for 3 in this case).
This commit changes `UsePath` so it also contains a
`PerNS<Option<Res<HirId>>>`. This type preserves more information and is
more self-documenting. The commit also changes a lot of the use sites to
access the result for a particular namespace. E.g. if you're looking up
a trait, it will be in the `Res` for the type namespace if it's present;
it's silly to look in the `Res` for the value namespace or macro
namespace. Overall I find the new code much easier to understand.
However, some use sites still iterate. These now use `present_items`
because that filters out the `None` results.
Also, `redundant_pub_crate.rs` gets a bigger change. A
`UseKind:ListStem` item gets no `Res` results, which means the old `all`
call in `is_not_macro_export` would succeed (because `all` succeeds on
an empty iterator) and the `ListStem` would be ignored. This is what we
want, but was more by luck than design. The new code detects `ListStem`
explicitly. The commit generalizes the name of that function
accordingly.
Finally, the commit also removes the `use_path` arena, because
`PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be
allocated in the arena shared by all `Copy` types.
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#141767 (ci: use free runner for aarch64-gnu-llvm-19-1 PR job)
- rust-lang/rust#141858 (Fix typo in `StructuralPartialEq` docs)
- rust-lang/rust#141865 (Optionally don't steal the THIR)
- rust-lang/rust#141874 (add f16_epsilon and f128_epsilon diagnostic items)
- rust-lang/rust#141904 (test-float-parse: apply `cfg(not(bootstrap))`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add f16_epsilon and f128_epsilon diagnostic items
cc https://github.com/rust-lang/rust/issues/116909
r? ``@tgross35``
|
|
Optionally don't steal the THIR
The THIR being stolen is a recurrent pain for authors of rustc drivers. This makes it optional, so that the `thir_body` query can still be used after analysis of the crate has completed.
|
|
r=petrochenkov
Fix false positive lint error from no_implicit_prelude attr
Fixes rust-lang/rust#141785
r? `@petrochenkov`
|
|
allow macro_use as first segment
Fixes rust-lang/rust#140255
This issue may raise a question: It's reasonable an external crate name or import target be legally named `macro_use`?
|
|
|
|
|
|
|
|
r=albertlarsan68,jieyouxu,mark-simulacrum,kobzol,jyn514,Noratrieb,WaffleLapkin,RalfJung,bjorn3
redesign stage 0 std
### Summary
**Blog post: https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/**
This PR changes how bootstrap builds the stage 1 compiler by switching to precompiled stage 0 standard library instead of building the in-tree one. The goal was to update bootstrap to use the beta standard library at stage 0 rather than compiling it from source (see the motivation at https://github.com/rust-lang/compiler-team/issues/619).
Previously, to build a stage 1 compiler bootstrap followed this path:
```
download stage0 compiler -> build in-tree std -> compile stage1 compiler with in-tree std
```
With this PR, the new path is:
```
download stage0 compiler -> compile stage1 compiler with precompiled stage0 std
```
This also means that `cfg(bootstrap)`/`cfg(not(bootstrap))` is no longer needed for library development.
### Building "library"
Since stage0 `std` is no longer in-tree `x build/test/check library --stage 0` is now no-op. The minimum supported stage to build `std` is now 1. For the same reason, default stage values in the library profile is no longer 0.
Because building the in-tree library now requires a stage1 compiler, I highly recommend library developers to enable `download-rustc` to speed up compilation time.
<hr>
**Blog post: https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/**
If you encounter a bug or unexpected results please open a topic in the [#t-infra/bootstrap](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap) Zulip channel or create a [bootstrap issue](https://github.com/rust-lang/rust/issues/new?template=bootstrap.md).
(Review thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Review.20thread.3A.20stage.200.20redesign.20PR/with/508271433)
~~Blocked on https://github.com/rust-lang/rust/pull/122709~~
try-job: dist-x86_64-linux
try-job: `x86_64-msvc*`
try-job: `x86_64-apple-*`
try-job: `aarch64-apple`
try-job: x86_64-gnu
try-job: `x86_64-gnu-llvm*`
|
|
Merge coroutine obligation checking into borrowck parallel loop
r? `@ghost`
attempts at increasing parallelism in parallel rustc by merging parallel blocks that run in sequence
|
|
|
|
|
|
Improve intrinsic handling in cg_ssa (part 2)
* Avoid computing function type and signature for intrinsics where possible
* Nicer handling of bool returning intrinsics
Follow up to https://github.com/rust-lang/rust/pull/141404
|
|
|
|
|
|
Add unimplemented `current_dll_path()` for WASI
This is the only change needed to Rust to allow compiling rustfmt for WASI (rustfmt uses some internal rustc crates).
|
|
Drive-by refactor: use `OnceCell` for the reverse region SCC graph
During region inference, the reverse SCC region graph is sometimes computed lazily. This changes the implementation for that from using an `Option` to a `OnceCell` which clearly communicates the intention and simplifies the code somewhat.
There shouldn't be any performance impact, except that this pulls the computation of the reverse SCC graph slightly later than before, and so may avoid computing it in some instances.
Note that this changes a mutable reference into an immutable (interior mutable) one.
|
|
lolbinarycat:rustdoc-source_span_for_markdown_range-bug-141665, r=GuillaumeGomez
source_span_for_markdown_range: fix utf8 violation
it is non-trivial to reproduce this bug through rustdoc, which uses this function less than clippy, so the regression test was added as a unit test instead of an integration test.
fixes https://github.com/rust-lang/rust/issues/141665
r? ``@GuillaumeGomez``
|
|
implement `va_arg` for `powerpc`
tracking issue: https://github.com/rust-lang/rust/issues/44930
The llvm `va_arg` implementation is well-known to have serious limitations. Some planned changes to rust's `VaList` make it much more likely that LLVM miscompiles `va_arg`, so this PR adds support for the various powerpc targets. Now at least the targets that `core` has explicit support for will continue to work.
For `powerpc` (the 32-bit variant) this implementation also fixes a bug where only up to 20 variadic arguments were supported.
Locally (with qemu), these targets now pass the tests in https://github.com/rust-lang/rust/blob/master/tests/run-make/c-link-to-rust-va-list-fn/checkrust.rs. That test does not actually run for the powerpc targets in CI though.
The implementation is based on clang:
- handling of big endian architectures https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/ABIInfoImpl.cpp#L191-L193
- 64-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L969
- 32-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L430
cc `@daltenty` (target maintainer)
r? `@workingjubilee`
`@rustbot` label: +F-c_variadic
|
|
Improve diagnostics for usage of qualified paths within tuple struct exprs/pats
For patterns the old diagnostic was just incorrect, but I also added machine applicable suggestions.
For context, this special cases errors for `<T as Trait>::Assoc(..)` patterns and expressions (latter is just a call). Tuple struct patterns and expressions both live in the value namespace, so they are not forwarded through associated *types*.
r? ``@jdonszelmann``
cc ``@petrochenkov`` in https://github.com/rust-lang/rust/pull/80080#issuecomment-800630582 you were wondering why it doesn't work for types, that's why — tuple patterns are resolved in the value namespace.
|
|
|
|
Tweak fast path trait handling
(1.) Make it more sound by considering polarity (lol)
(2.) Make it more general, by considering higher-ranked size/copy/clone
(2.) Make it less observable, by only doing copy/clone fast path if there are no regions involved
r? lcnr
|
|
don't ICE now
|
|
This is the only change needed to Rust to allow compiling rustfmt for WASI (rustfmt uses some internal rustc crates).
|
|
r=nnethercote
cstore: Use IndexSet as backing store for postorder dependencies
`<rustc_metadata::creader::CStore>::push_dependencies_in_postorder` showed up in new benchmarks from https://github.com/rust-lang/rustc-perf/pull/2143, hence I gave it a shot to remove an obvious O(n) there.
r? nnethercote
|
|
Avoid over-counting of `UsePath` in the HIR stats.
Currently we over-count. Details in the individual commits.
r? `@BoxyUwU`
|
|
This helps with efforts to deduplicate the `MutVisitor` and the
`Visitor` code. All users of `Visitor`'s methods that have extra
`NodeId` as parameters really just want to visit the id on its
own.
Also includes some methods deduplicated and cleaned up as
a result of this change.
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#141072 (Stabilize feature `result_flattening`)
- rust-lang/rust#141215 (std: clarify Clone trait documentation about duplication semantics)
- rust-lang/rust#141277 (Miri CI: test aarch64-apple-darwin in PRs instead of the x86_64 target)
- rust-lang/rust#141521 (Add `const` support for float rounding methods)
- rust-lang/rust#141812 (Fix "consider borrowing" for else-if)
- rust-lang/rust#141832 (library: explain TOCTOU races in `fs::remove_dir_all`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This actually fixes a bug where before only 20 arguments could be passed. As far as I can tell, an arbitrary number of arguments is now supported
|
|
Fix "consider borrowing" for else-if
Fixes rust-lang/rust#141810
When trying to suggest a borrow on a `if` or `block` expression, instead we now recurse into the `if` or `block`.
The comments in the code should explain the goal of the new code.
r? ``@jdonszelmann``
|
|
Add `const` support for float rounding methods
# Add `const` support for float rounding methods
This PR makes the following float rounding methods `const`:
- `f64::{floor, ceil, trunc, round, round_ties_even}`
- and the corresponding methods for `f16`, `f32` and `f128`
Tracking issue: https://github.com/rust-lang/rust/issues/141555
## Procedure
I followed https://github.com/rust-lang/rust/commit/c09ed3e767a73d83673790f74c357432fa44d320 as closely as I could in making float methods `const`, and also received great guidance from https://internals.rust-lang.org/t/const-rounding-methods-in-float-types/22957/3?u=ruancomelli.
## Note
This is my first code contribution to the Rust project, so please let me know if I missed anything - I'd be more than happy to revise and learn more. Thank you for taking the time to review it!
|
|
Stabilize feature `result_flattening`
Stabilizes the `Result::flatten` method
## Implementations
- [x] Implementation `Result::flatten`: https://github.com/rust-lang/rust/pull/70140
- [x] Implementation `const` `Result::flatten`: https://github.com/rust-lang/rust/pull/130692
- [x] Update stabilization attribute macros (this PR)
## Stabilization process
- [x] Created this PR [suggested](https://github.com/rust-lang/rust/issues/70142#issuecomment-2885044548) by ``@RalfJung``
- [x] FCP (haven't found any, is it applicable here?)
- [ ] Close issue rust-lang/rust#70142
|
|
`slice.get(i)` should use a slice projection in MIR, like `slice[i]` does
`slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.
This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement. (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.)
I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition. Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata. But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`. Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.
Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
|
|
it is non-trivial to reproduce this bug through rustdoc,
which uses this function less than clippy,
so the regression test was added as a unit test
instead of an integration test.
|
|
Add const support for the float rounding methods floor, ceil, trunc,
fract, round and round_ties_even.
This works by moving the calculation logic from
src/tools/miri/src/intrinsics/mod.rs
into
compiler/rustc_const_eval/src/interpret/intrinsics.rs.
All relevant method definitions were adjusted to include the `const`
keyword for all supported float types: f16, f32, f64 and f128.
The constness is hidden behind the feature gate
feature(const_float_round_methods)
which is tracked in
https://github.com/rust-lang/rust/issues/141555
This commit is a squash of the following commits:
- test: add tests that we expect to pass when float rounding becomes const
- feat: make float rounding methods `const`
- fix: replace `rustc_allow_const_fn_unstable(core_intrinsics)` attribute with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
- revert: undo update to `library/stdarch`
- refactor: replace multiple `float_<mode>_intrinsic` rounding methods with a single, parametrized one
- fix: add `#[cfg(not(bootstrap))]` to new const method tests
- test: add extra sign tests to check `+0.0` and `-0.0`
- revert: undo accidental changes to `round` docs
- fix: gate `const` float round method behind `const_float_round_methods`
- fix: remove unnecessary `#![feature(const_float_methods)]`
- fix: remove unnecessary `#![feature(const_float_methods)]` [2]
- revert: undo changes to `tests/ui/consts/const-eval/float_methods.rs`
- fix: adjust after rebase
- test: fix float tests
- test: add tests for `fract`
- chore: add commented-out `const_float_round_methods` feature gates to `f16` and `f128`
- fix: adjust NaN when rounding floats
- chore: add FIXME comment for de-duplicating float tests
- test: remove unnecessary test file `tests/ui/consts/const-eval/float_methods.rs`
- test: fix tests after upstream simplification of how float tests are run
|
|
Enable non-leaf Frame Pointers for mingw-w64 Arm64 Windows
Based on https://github.com/rust-lang/rust/pull/140828
I don't have AArch64 Windows to test it, but I trust LLVM to handle it well.
|
|
Hir item kind field order
A follow-up to rust-lang/rust#141675.
r? `@fee1-dead`
|
|
Note expr being cast when encounter NonScalar cast error
Fixes #140491
I added note for `expr` so that it doesn't treat `&x as T` as `&(x as T)` but `(&x) as T`. But I'm not sure if I want to add note for all NonScalar, maybe for specific `expr_ty`?
r? compiler
|
