Repository navigation
Conversation
Similar to the existing tests for other `cfg`s like `no_fp_fmt_parse`, add one for `no_io_statics`. This should prevent issues like the one in the parent commit. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Document layout of Saturating, similarly to Wrapping
… GCC do LTO when using rustc_codegen_gcc
Co-Authored-By: Brian Smith <brian@briansmith.org> Co-Authored-By: Ralf Jung <post@ralfj.de>
Emit llvm dereferenceable in more cases on newer LLVM versions On llvm >= 23 emit `dereferenceable` even without `nofree`, since llvm/llvm-project#204795 makes `dereferenceable` act "at a point" / not imply `nofree`. Additionally restrict `dereferenceable` to `&Freeze` / `&mut Unpin` / `Box<Unpin, _>` only (this is only relevant for `llvm >= 23` as otherwise `!Freeze`/`!Unpin` suppress `nofree` and as such `dereferenceable`). r? nikic I thought this will be a bit harder change, but since your refactoring in rust-lang#156281 it's actually trivial ^^' Draft because I don't think this can be tested prior to LLVM update. I'm also not sure if the version check I did is the appropriate one... cc @RalfJung
…cci, r=Kobzol Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs" Reverts rust-lang#162339 Re-applies rust-lang#161716 and rust-lang#162318 Since a new beta has been released between then and now, the fix applied in rust-lang#162346 is in beta, so the code should work. r? @jieyouxu
…rust-lang#151770, r=tgross35 Add mul_add_relaxed methods for floating-point types Implements mul_add_relaxed for f16, f32, f64, and f128, which computes (self * a) + b with relaxed precision semantics. Unlike mul_add which guarantees a fused operation, this variant allows the compiler to choose between fused or separate operations based on target performance. This fills the gap between the precision-guaranteed mul_add and the fully-optimizable algebraic operators, providing target-specific optimization while maintaining reasonable floating-point semantics. Tracking issue: rust-lang#151770 try-job: dist-i586-gnu-i586-i686-musl
Fix rustdoc ICE caused by mishandling of ambiguity errors Fixes rust-lang#162557 ```rust pub trait Service<Request> { type Future; } pub trait ZebraService<Request>: Service<Request> {} impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where MaybeVerify: Service<Request, Future: 'static> { } pub struct Verifier; impl Service<()> for Verifier { type Future = &'static (); } ``` In the above minimization of the issue, when we try to check whether the blanket impl can be applied to `Verifier`, https://github.com/rust-lang/rust/blob/a8a1e6fd9df2e094d6f09c0d57991508680acc1c/src/librustdoc/clean/blanket_impl.rs#L42-L67 We make fresh args for the where-clause and skip normalization for it. So, we have `<?MaybeVerify as Service<?Request>>::Future: 'static` bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars. But due rust-lang#162182 we evaluated it directly in the solver without `stalled_on` and this time it succeeded because we can normalize the alias into a concrete type `&'static ()` and it outlives the static region. So, I think it's very iffy to call `InferCtxt::evaluate_obligation` on a non-rigid alias and we should eagerly normalize it in `L67` from the above rustdoc code. But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs. r? lcnr
…mulacrum Miri can do dirfd now So let's remove some special-casing from the standard library. Fixes rust-lang/miri#5327
…-perf, r=nnethercote Improve `DocStrings` perf Follow-up of rust-lang#162862. r? ghost
…=lcnr Fix `TypeOutlives` fast-path > Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path: > > `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases > > This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush: _Originally posted by @lcnr in rust-lang#162782 (comment) The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD. We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver. I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but.. - It's no-less-correct than the status quo - It roughly matches the actual non-fast path: https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129 - The later has some perf impact hard to ignore for `typenum` I couldn't conjure up any case fixed by this PR other than the one in rust-lang#162782 😅 r? lcnr
…s, r=petrochenkov Several small span improvements Limit changes: - Increase `MAX_CTXT`: it is currently `0b0111_1111_1111_1110` (~15 bits). But it only needs to be distinguishable from `CTXT_INTERNED_MARKER` (all 1s). So we can increase it to `0b1111_1111_1111_1110` (~16 bits). The old limit is rarely reached; the `uom` crate is an exception (it has 39k contexts) and we see a 1-2% instruction count reduction when building it. (This value was incorrectly reduced from ~16 bits to ~15 bits in e525e4f by me; apologies!) Renamings: - Rename `MAX_CTXT` as `MAX_CTXT_OR_PARENT` because it also relates to the parent field. - Remove the `BASE_` prefix from `BASE_LEN_INTERNED_MARKER` because it doesn't mean anything. Comments: - Update parts of the comment that predate the addition of the `parent` field, such as the frequency measurements. (In incremental builds, 20-40% internment due to non-root context and non-zero parent is common.) - Slightly clarify the meanings of the fields in the different forms, and add a paragraph quickly explaining which specific values distinguish the four forms. r? @petrochenkov
…i-obk Reorganise reflection intrinsics Trivial refactor moving some things around. We got a fair amount of intrinsics for reflection now with more on the way. At this point it's worth it to reorganize things a little. This prefixes them with `type_id_` (`TypeId` is the entry point for _nearly_ all of reflection) and moves their declaration into its own module (`core::intrinsics::reflection`). Possible contentious is the move of the `type_id` intrinsic which has existed for a while and was previously at `core::intrinsics::type_id`. It is still unstable and as far as I am aware intrinsics should really not be relied upon by users. I've decided to leave the `field_representing_field` (name, offset, actual_type_of) where they are since those where not created for reflection and will be changed in the future (see: rust-lang#162127). r? oli-obk
…i-obk fix `ValidateBoundVars` `ControlFlow::Break` is just wrong. We want to visit later types even if we skip the current one. The `t.outer_exclusive_binder() <= self.binder_index` check is more subtle. See the flag computation https://github.com/rust-lang/rust/blob/29df41c47187f735942d13900b784962ef1bc140/compiler/rustc_type_ir/src/flags.rs#L217-L218 It is the exclusive binder. The first binder for which there exist no bound vars. This is subtle and was found while asking an LLM to help with perrrrf, only for me to then be confused for 10 min while checking whether this is right :< r? types
…-obk bump rustc-build-sysroot Fixes rust-lang/miri#5371 r? @oli-obk
Revert note about signum of NaN See: rust-lang#162576 (comment)
Add mailmap entry Done at the request of the user. CC @LoriLorusso
…piler_entrypoint, r=oli-obk Rename `rustc_driver::run_compiler` to `compiler_entrypoint` Having two `run_compiler` functions has always been confusing and not necessary at all, as they perform fairly different functions. Even more so because `rustc_driver::run_compiler` calls to `rustc_interface::run_compiler`. So it seems like a recursive function when it really isn't.
Remove variants from `feature-gate-autodiff-use` test Both the stable and nightly variants were the same; the test didn't actually test what it thought, because compiletest enables `RUSTC_BOOTSTRAP=1` unconditionally. CC @ZuseZ4 r? jieyouxu
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
…li-obk document the rustc_comptime attribute r? @oli-obk
Skip optional asserts in SsaRangePropagation Fixes rust-lang#163779. Is it normal to have a mir-opt diff without any diff in it? I think it communicates what I want in this case, that the pass does nothing to this code.
Bump Windows CI LLVM to 22.1.8 It's fallen a bit behind the linux runners. Also needed for running `tests/debuginfo` on windows CI runners (rust-lang#163090)
continue crashes tests `-Znext-solver` work cc rust-lang#140211 rust-lang#119786 rust-lang#155497 rust-lang#110534 rust-lang#102252 rust-lang#120254 rust-lang#115435 rust-lang#122529 rust-lang#119095 rust-lang#124440
…cl, r=BoxyUwU Get `inputs_hir` directly from `decl` Just a small pass-by improvement while I'm working on something bigger
…-spaces, r=JohnTitor Fix extra spaces in integer format_into docs
…-actions, r=Kobzol Update GitHub Actions to v26 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [ubuntu](https://redirect.github.com/actions/runner-images) | github-runner | major | `24.04` → `26.04` | | [ubuntu](https://redirect.github.com/actions/runner-images) | github-runner | major | `24.04-arm` → `26.04-arm` | --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - Between 12:00 AM and 03:59 AM, only on Monday (`* 0-3 * * 1`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/rust-lang/rust). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMjUuMSIsInVwZGF0ZWRJblZlciI6IjQ0LjEyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
…generics-check, r=JonathanBrouwer moves rustc_legacy_const_generics checks into attribute parsing Part of rust-lang#153101. Moves the remaining `#[rustc_legacy_const_generics]` validation from `rustc_passes::check_attr` into `RustcLegacyConstGenericsParser::finalize_check`. The three associated diagnostics are moved into `rustc_attr_parsing`, and the old check is removed from `check_attr.rs`. Diagnostic messages and spans are preserved.
…, r=lcnr Fix an issue for clippy's `search_is_some` with the next-solver r? lcnr
…nathanBrouwer Rollup of 11 pull requests Successful merges: - rust-lang#163364 (make semicolon_in_expressions_from_non_local_macros not report-in-deps) - rust-lang#163531 (rustc_ast_lowering: track implicit Self via explicit flag instead of name) - rust-lang#163770 (document the rustc_comptime attribute) - rust-lang#163780 (Skip optional asserts in SsaRangePropagation) - rust-lang#163785 (Bump Windows CI LLVM to 22.1.8) - rust-lang#163796 (continue crashes tests `-Znext-solver` work) - rust-lang#163646 (Get `inputs_hir` directly from `decl`) - rust-lang#163733 (Fix extra spaces in integer format_into docs) - rust-lang#163773 (Update GitHub Actions to v26) - rust-lang#163787 (moves rustc_legacy_const_generics checks into attribute parsing) - rust-lang#163810 (Fix an issue for clippy's `search_is_some` with the next-solver)
This reverts commit 0cacc05.
[rustdoc] Fix how `Deref` items is handled. Fixes rust-lang#160236. This PR fixes a few things around how we handle `Deref`: * Since nothing except for methods is callable through a `Deref`, only methods should be kept * If the `Deref::Target` is a type implementing `Copy`, then methods taking `self` work and should be displayed. <del>During the `clean` pass, I store the item `DefId` on which `Deref` is implemented in a `DefIdSet` if the `Deref::Target` implements `Copy`. Then during rendering, we check if the "parent item" is in in the `DefIdSet`, and if so, we keep methods with `self`.</del> <del>Now you might wonder why the item and not the derefed item. It's because the `DefId` we get from the computed type doesn't match the `DefId` of the actual type (that's where I spent most of my time, finding an ID (`DefId`/`ItemId`) I can use as key T_T).</del> It computes in `html/render` if the `Deref::Target` item is copy before rendering it. So to resume: * `&self` is always kept. * `&mut self` is kept if `DerefMut` is implemented (nothing changed there). * `self` is kept only if `Deref::Target` is `Copy`. * Everything else disappears as they're not callable through `Deref`. r? @camelid
…ath, r=BoxyUwU fix `VisibleForLeakCheck` in `RegionOutlives` fast path This causes the new solver to more closely match the old solver. `-Zdisable-fast-paths` already causes this to fail on nightly. This is a small bug in the impl of rust-lang#155749. We should have probably FCP'd that change as it was a breaking change to coherence. I forgot to do so after mentioning its impact on coherence in rust-lang#155749 (review). This PR causes the following snippet to no longer compile: ```rust trait MayRequireStatic {} // `for<'a> &'a i32: MayRequireStatic` does not hold impl<'a: 'static> MayRequireStatic for &'a i32 {} impl<'a> MayRequireStatic for &'a u32 {} trait Trait {} impl Trait for i32 {} impl<T> Trait for T where for<'a> &'a T: MayRequireStatic {} fn is_trait<T: Trait>() {} fn main() { is_trait::<i32>(); is_trait::<u32>(); } ``` This feels very artificial to me. I guess let's still do a quick FCP for this breakage. no clue why we're missing a span with the old solver here 🤣 r? BoxyUwU
…, r=JonathanBrouwer Move #[doc(inline)] and #[doc(no_inline)] validation into rustc_attr_parsing Part of rust-lang#153101 This migrates `#[doc(inline)]` and `#[doc(no_inline)]` validation from `rustc_passes` into `DocParser` in `rustc_attr_parsing`. It checks for conflicting inlining attributes and non-use targets, and tweaks rustdoc's early abort so lowering errors don't suppress other attribute diagnostics, also added new UI tests in doc-inline-validation.rs.
…n, r=notriddle When documenting without a specified `--edition`, emit a message Follow-up of rust-lang#158102. cc @estebank r? @notriddle
…they Add some comments and docs related to `AllocatorNightly` Follow-up to rust-lang#163590 (comment) and [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/197181-t-libs.2Fwg-allocators/topic/.60AllocatorNightly.60.20auto-trait.3F/near/629283171)
These trailing spaces are fairly old, back in 1.87.0, but my editor has been flagging them as warnings.
…nathanBrouwer Rollup of 5 pull requests Successful merges: - rust-lang#160915 ([rustdoc] Fix how `Deref` items is handled.) - rust-lang#163267 (fix `VisibleForLeakCheck` in `RegionOutlives` fast path) - rust-lang#163673 (Move #[doc(inline)] and #[doc(no_inline)] validation into rustc_attr_parsing) - rust-lang#163795 (When documenting without a specified `--edition`, emit a message) - rust-lang#163814 (Add some comments and docs related to `AllocatorNightly`)
[win][arm64] Revert the change to disable symlink tests for Arm64 Windows, and add a permission guard to the recursive_rmdir test PR rust-lang#140759 disabled all tests that use symlinks and junctions for Arm64 Windows, as the [GitHub runners at the time didn't have permissions to create them](https://github.com/actions/partner-runner-images/issues/94). This has now been fixed, so we can revert that change. I also added a guard into the `recursive_rmdir` as it was creating a symlink without first checking if we had permissions to do so. r? @RalfJung
Trim trailing whitespace from `RELEASES.md` These trailing spaces are fairly old, back in 1.87.0, but my editor has been flagging them as warnings.
Rollup of 2 pull requests Successful merges: - rust-lang#163835 ([win][arm64] Revert the change to disable symlink tests for Arm64 Windows, and add a permission guard to the recursive_rmdir test) - rust-lang#163844 (Trim trailing whitespace from `RELEASES.md`)
…026-10-05, r=jieyouxu rustfmt subtree update 2026-10-05 Subtree update of `rustfmt` to rust-lang/rustfmt@4368801 Created using https://github.com/rust-lang/josh-sync. I wanted to get a little hands on experience with the new josh sync tooling. Overall it's so much nicer to use than the older patched git subtree setup we were using! A fairly small sync, with one fix to `wrap_comments` from rust-lang/rustfmt#7156. r? @jieyouxu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Zulipchat topic link: Safety requirements of ARM hint APIs
This PR tries to remove the unsafe in
core_arch/arm_shared/hint.rs. As the Zulip topic discussed, these APIs have#[cfg(any(...))]attribute to restrict that these can only be compiled when specific architecture is met. So there seems no need to mark these APIs unsafe.But there is a remaining question: For
wfeandwfi, they can be configurable to trap. So I think if needed, I can complement some discription about trap. Hoping you can give me some suggestion.