Rollup of 7 pull requests#158629
Merged
Merged
Conversation
ACP: <rust-lang/libs-team#799> Tracking issue: <rust-lang#157345> The docs are mostly copied from `Box::as_mut_ptr()`
Add built-in OpenEmbedded/Yocto Linux targets for x86_64, i686, aarch64, armv7, and riscv64. These targets inherit from the corresponding upstream Linux GNU targets and provide OpenEmbedded-specific target triples and default linker settings. They are intended to serve as base targets for downstream Yocto/OpenEmbedded-generated targets, allowing vendor-specific targets to override metadata (for example, TARGET_VENDOR) while reusing a common target configuration. This reduces duplication in Yocto-based Rust integrations and avoids maintaining downstream copies of largely identical target specifications. Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
…ne)]` is working as expected
The previous error message made it sound like stage != 2 was entirely disallowed under CI. But actually it was only *implicit* stage != 2 which is disallowed - an explicit `--stage 1` is permitted and is sometimes correct. Minimal command to trigger the error message: `GITHUB_ACTIONS=true ./x test ui`
This allows us to depend on `rustc_resolve` from `rustc_incremental`. Important for rust-lang/rust-project-goals#641
lint on `core::ffi::c_void` as a return type Fixes rust-lang#100972. This PR introduces a new ~deny-by-default~ warn-by-default lint `c_void_returns` that fires on usage of `core::ffi::c_void` as a return type. This is never correct, and is a potential stumbling block for users coming from C.
…sonn Implement `Box::as_non_null()`. ACP: <rust-lang/libs-team#799> Tracking issue: <rust-lang#157345> The docs are mostly copied from `Box::as_mut_ptr()` I also made a drive-by change to add `#[must_use]` to `Box::as_{ptr, mut_ptr}`. I'm unsure what `#[rustc_never_returns_null_ptr]` and `#[rustc_as_ptr]` do. Should `Box::as_non_null()` be annotated with them? r? libs-api
…vidtwco rustc_target: Add OpenEmbedded/Yocto Linux base targets Add built-in OpenEmbedded/Yocto Linux targets for x86_64, i686, aarch64, armv7, and riscv64. These targets inherit from the corresponding upstream Linux GNU targets and provide OpenEmbedded-specific target triples and default linker settings. They are intended to serve as base targets for downstream Yocto/OpenEmbedded-generated targets, allowing vendor-specific targets to override metadata (for example, TARGET_VENDOR) while reusing a common target configuration. This reduces duplication in Yocto-based Rust integrations and avoids maintaining downstream copies of largely identical target specifications. **Tier 3 Policy Notes** To cover the Tier 3 requirements: > A tier 3 target must have a designated developer or developers These targets have a designated maintainer: @DeepeshWR, as documented in the platform support documentation added by this PR. > Targets must use naming consistent with any existing targets The targets follow the existing target naming conventions and are derived from the corresponding upstream Linux GNU targets: ``` x86_64-oe-linux-gnu aarch64-oe-linux-gnu i686-oe-linux-gnu armv7-oe-linux-gnueabihf riscv64-oe-linux-gnu ``` The oe vendor component identifies OpenEmbedded/Yocto-based systems while preserving the established architecture/OS/ABI naming scheme. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users These targets do not introduce any additional legal requirements. They use the standard OpenEmbedded/Yocto cross-compilation toolchains and are intended to behave similarly to the corresponding Linux GNU targets. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate These targets inherit from the corresponding Linux GNU targets and support the standard library in the same manner as their upstream counterparts. > The target must provide documentation for the Rust community explaining how to build for the target This PR adds platform-support documentation describing the targets, maintainership, requirements, and intended usage. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target The targets are thin wrappers around existing Linux GNU targets and primarily provide canonical OpenEmbedded/Yocto target triples and default linker configuration. They do not require additional CI infrastructure or special maintenance beyond keeping them aligned with their upstream Linux GNU base targets. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target Noted. > Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target These targets use LLVM through the existing Rust code generation pipeline, just like their corresponding Linux GNU targets. r? @davidtwco
…gn-inlining, r=Urgau [rustdoc] Fix handling of inlining of `no_inline` of foreign items Fixes rust-lang#92379. The magic of `reexport_chain` (and what happens when we forget to use it 😆 ). r? @camelid
…_mut, r=clarfonthey stabilize `feature(atomic_from_mut)` Completed FCP: rust-lang#76314 (comment) Closes rust-lang#76314
…-message, r=clubby789 Fix error message when rejecting implicit stage != 2 in CI The previous error message made it sound like stage != 2 was entirely disallowed under CI. But actually it was only *implicit* stage != 2 which is disallowed - an explicit `--stage 1` is permitted and is sometimes correct. Minimal command to trigger the error message: `GITHUB_ACTIONS=true ./x test ui`
…endents, r=petrochenkov Remove dependency from `rustc_metadata` on `rustc_incremental` This allows us to depend on `rustc_resolve` from `rustc_incremental`. Important for rust-lang/rust-project-goals#641
rustbot
added
S-waiting-on-review
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jun 30, 2026
Rollup of 7 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-2
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 3bdb179 failed: CI. Failed job:
|
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
rustbot
removed
the
S-waiting-on-author
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: f46ec5218f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 f46ec52 (parent) -> 17aa775 (this PR) Test differencesShow 1381 test diffsStage 0
Stage 1
Stage 2
Additionally, 1354 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 17aa77551e89d5e80d4b506c9a32fc151264b8e4 --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 (17aa775): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@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 -4.8%, secondary -4.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -4.3%, secondary -7.7%)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: 485.565s -> 486.291s (0.15%) |
Contributor
rustbot
added
the
perf-regression-triaged
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
12 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:
core::ffi::c_voidas a return type #156379 (lint oncore::ffi::c_voidas a return type)Box::as_non_null(). #157347 (ImplementBox::as_non_null().)no_inlineof foreign items #158569 ([rustdoc] Fix handling of inlining ofno_inlineof foreign items)feature(atomic_from_mut)#158573 (stabilizefeature(atomic_from_mut))rustc_metadataonrustc_incremental#158616 (Remove dependency fromrustc_metadataonrustc_incremental)r? @ghost
Create a similar rollup