Rollup of 13 pull requests - #163363
Merged
Merged
Rollup of 13 pull requests#163363
Conversation
Tracking issue: rust-lang#95383
In 5d81891 ("Always inline functions signatures containing `f16` or `f128`"), these types were changed to automatically inline so codegen wouldn't crash on poorly-supported platforms. We have since gained a cfg to reflect the type's codegen reliability. Update so we only check and auto-inline based on type if this config is set, which makes `f16` and `f128` act more like any other type on most platforms. We still can't remove this entirely since a lot of API in `std` wouldn't get inlined and would crash the few remaining poorly-supported backend+target combinations.
There is one match arm handling some `ForceWarning` cases and another arm handling the remaining `ForceWarning` case and also `Expect`. They can be rearranged into one arm handling `ForceWarning` and one arm handling `Expect`. Also fix some comments: - `ForceWarning` no longer has a field. - Clarify the `LintExpectationId` location. - The one about deduplication was inverted.
I think the ship has sailed on the "every error should have an error code" idea and it's not worth pretending otherwise.
This is a part of the stack-protector work. Adding support for merge-functions is not strictly needed, but it does prevent breakage if the GCC function merging logic changes. Not adding tests for -Z merge-functions since I don't see any such tests for the LLVM side of it.
we can pass it by reference when we have it (loan traversal), and use the one in regioncx's LivenessValues when we don't have it already in scope (MIR dump traversal)
we're really deferring the region liveness computation to become on-demand, "deferred locals" is slightly inaccurate in that some of the local's type data is also necessary for drop-liveness. we can focus on the output of the computation rather than its inputs. it also allows us to rename the suboptimal set of locals `deferred` colliding with `deferred_locals`
rename the various `deferred` to mention locals, now that `DeferredLocals` doesn't use `deferred_locals`
by not calling `compute_relevant_live_locals`: - remove free regions hashset allocation - remove unused boring locals allocation - remove relevant locals vec allocation - directly build relevant locals with nll_boring locals filtering we could also optimize the boring nll locals hashset but it's unclear whether it's worth it compared to when it's being iterated.
we previously always created an unsolved regioncx to immediately solve it, but can create the solved regioncx in a single step. this is done by merging `UnsolvedRegionInferenceContext`'s `new` and `solve` into one constructor.
When a derive macro expands the annotated item's name directly using `quote!`, it keep the item's Span context (instead of having a new context). This means that the generic Span context machinery which provides feedback that an error happened due to a derive doesn't kick in. If a derive macro isn't written to take into account the existence of type parameters, an error for "mismatched number of type parameters" will be emitted. We now detect the case when this happens due to the derive macro, and customize the output to point that out, as well as avoid giving suggestions that will always be wrong.
Because they're all just special cases of warnings. This requires introducing a new `Option<EmissionOverride>` field to `Warning` that describes the special case behaviour; the `DiagInner::lint_id` field also gets merged in. Specific nice things about this: - Removes some unreachable match arms for `Allow`/`Expect`. - Removes the hacky upgrading of `Allow`/`Expect` to `Warning` in `emit_future_breakage_report`. - The types now have structure that used to be maintained by comments and assertions. E.g. it's now impossible to not have a `lint_id` for an `expect` lint. (I always found the `DiagInner::lint_id` field confusing; it's clearer now.) - There's a nice comment on `EmissionOverride` summarizing all the different cases. - A little less code overall.
Detect bad number of generics caused by bad derive When a derive macro expands the annotated item's name directly using `quote!`, it keep the item's Span context (instead of having a new context). This means that the generic Span context machinery which provides feedback that an error happened due to a derive doesn't kick in. If a derive macro isn't written to take into account the existence of type parameters, an error for "mismatched number of type parameters" will be emitted. We now detect the case when this happens due to the derive macro, and customize the output to point that out, as well as avoid giving suggestions that will always be wrong. Partially address rust-lang#160463 (this doesn't detect a nameres error caused by referencing type parameter within a derive). ``` error[E0107]: missing generics for enum `A` --> bar.rs:8:6 | 7 | #[derive(A)] | - it looks like this derive macro might not support items with generic parameters 8 | enum A<T> { | ^ ``` r? @petrochenkov
…larfonthey Add some docs to `Global` r? libs
…t, r=jieyouxu simplify ndk compiler test
rustbot
added
A-compiletest
Member
Author
|
@bors r+ p=5 force |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Sep 26, 2026
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 90c195e (parent) -> fd98695 (this PR) Test differencesShow 69 test diffsStage 0
Stage 1
Stage 2
Additionally, 40 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard fd98695850065878fa7de48808dca4f0901cefbb --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (fd98695): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.8%, secondary 0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -13.3%, secondary -1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 487.474s -> 490.11s (0.54%) |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: 90c195e097 In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
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
14 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.
Successful merges:
f16andf128on well-supported platforms #162883 (No longer auto-inlinef16andf128on well-supported platforms)#[rustc_allow_incoherent_impl]is involved #163133 ([rustdoc] Fix invalid jump to def link when#[rustc_allow_incoherent_impl]is involved)ForceWarning/Allow/ExpectintoWarning#163290 (MergeForceWarning/Allow/ExpectintoWarning)mem::conjure_zst#161710 (Stabilizemem::conjure_zst)Global#163332 (Add some docs toGlobal)r? @ghost
Create a similar rollup