Rollup of 11 pull requests - #161093
Conversation
The goal here is to *reduce the amount of slop PRs*, not as a blanket endorsement of using agents to work on `rust-lang/rust`. To that end, I have [done extensive testing][ETOOMANYLUNAS] to make sure the new file actually helps that goal. [ETOOMANYLUNAS]: https://github.com/jyn514/ETOOMANYLUNAS The results are promising. They show agents consistently asking their users to confirm they're read their own work; requiring users to write their own PR descriptions; and pointing people to other repos if they try to modify a submodule or subtrees, as well as various other tests. --- Summary of the AGENTS.md (taken from the test repo: This is a rather long operationalization of the [dev-guide] as algorithmic instructions. Most of it was itself generated with an agent. Differences between this and the [dev-guide] / [policy]: [dev-guide]: https://rustc-dev-guide.rust-lang.org/llm-guidance.html [policy]: https://forge.rust-lang.org/policies/llm-usage.html - "strong suggestions" in the docs are turned into absolute requirements here; LLMs have trouble with discretion and judgement. - lang/edition/etc are not exempted; determining what falls under their scope was too hard to operationalize. members of those teams can still write their own AGENTS.md if this one interferes with their work (i wouldn’t expect it to, though, it’s mostly focused on code.) - the LLM requires a reviewer before making edits, not before posting the PR. experimental PRs are not exempted (how could the LLM know it was experimental?). - soundness changes are always rejected, even if allowed by the policy (how could the LLM know you’re in the org?)
This adds one vendor-specific file, for the benefit of getting Claude to actually follow the instructions. I've put this in a separate commit so that I can drop it if people feel strongly. I *highly recommend* that we add a CLAUDE.md, it really makes a difference. You can see examples of what Claude does without a file in the [testing repo][ETOOMANYLUNAS]. [ETOOMANYLUNAS]: https://github.com/jyn514/ETOOMANYLUNAS
…r pr descriptions Co-authored-by: Josh Triplett <josh@joshtriplett.org>
`rerunning_stalled_goal_may_make_progress` is split into always-inline and never-inline variants, because it's biggish and has multiple call sites but only one is hot. The other are easy, being either very small or having a single call site.
When encountering a resolve error on a type parameter associated item constraint (which can be caused by a typo when trying to write a path), do not *also* complain about associated items not being able to be constrained there.
…at didn't resolve, silence error When typoing `Vec<foo::Bar>` to `Vec<foo:Bar>`, do not emit error complaining about the wrong number of type parameters for `Vec`.
Enable `static_position_independent_executables` on all gnu targets Glibc has supported static PIE for a while, so there's no reason to ever build a non-PIE executable with a modern toolchain.
…e, r=Amanieu PowerPC inline ASM: Fix scalar floats being in the wrong vector lane on little endian 64-bit PowerPC supports both big and little endian, however registers are always big endian. As a consequence of this, the order of vector lanes is reversed on little endian; however scalar `f32` and `f64` are always stored in the actual (big-endian) lane 0. This PR fixes the LLVM ASM fixup to take that into account. Ping target maintainers: @daltenty @gilamn5tr @amy-kwan @Gelbpunkt @famfo @neuschaefer
Miri: give the incremental session a chance to finish This helps with rust-lang/miri#5013. Reruns still aren't as fast as I'd like, but using nextest to run libcore tests shows a big difference: ``` before: Nextest run ID 56b7b355-6225-4083-96e3-aeeabbe80523 with nextest profile: default-miri Starting 10 tests across 2 binaries (2760 tests skipped) PASS [ 31.264s] coretests::coretests any::any_downcast_mut PASS [ 31.287s] coretests::coretests any::distinct_type_names PASS [ 32.747s] coretests::coretests iter::traits::iterator::test_any PASS [ 32.758s] coretests::coretests any::any_owning PASS [ 32.864s] coretests::coretests any::dyn_type_name PASS [ 32.973s] coretests::coretests any::any_downcast_ref PASS [ 33.139s] coretests::coretests any::any_unsized PASS [ 33.719s] coretests::coretests any::any_referenced PASS [ 35.786s] coretests::coretests any::any_fixed_vec PASS [ 38.951s] coretests::coretests num::dec2flt::parse::many_digits ──────────── Summary [ 38.955s] 10 tests run: 10 passed, 2760 skipped after: Nextest run ID af603971-e41e-466d-8469-0425057fa325 with nextest profile: default-miri Starting 10 tests across 2 binaries (2761 tests skipped) PASS [ 15.063s] coretests::coretests any::any_unsized PASS [ 15.176s] coretests::coretests any::distinct_type_names PASS [ 15.200s] coretests::coretests any::any_referenced PASS [ 15.550s] coretests::coretests iter::traits::iterator::test_any PASS [ 15.993s] coretests::coretests any::any_fixed_vec PASS [ 17.506s] coretests::coretests num::dec2flt::parse::many_digits PASS [ 17.902s] coretests::coretests any::any_downcast_ref PASS [ 18.188s] coretests::coretests any::any_owning PASS [ 19.270s] coretests::coretests any::dyn_type_name PASS [ 19.702s] coretests::coretests any::any_downcast_mut ──────────── Summary [ 19.705s] 10 tests run: 10 passed, 2761 skipped ``` It still seems to spend at least 10s building the crate before Miri even begins running, no idea what it is doing in that time. But it's 15s less than before so that's good. :)
…=jdonszelmann Inline some hot new-solver functions `rerunning_stalled_goal_may_make_progress` is split into always-inline and never-inline variants, because it's biggish and has multiple call sites but only one is hot. The other are easy, being either very small or having a single call site. r? @jdonszelmann
Updates the expect messages in library/std/src/net/udp.rs to follow the style guide - [x] I did not use an LLM to create a change in this PR. - [ ] I used an LLM to create a change in this PR, and I have explained below how it was used.
Add an AGENTS.md that enforces the LLM policy The goal here is to *reduce the amount of slop PRs*, not as a blanket endorsement of using agents to work on `rust-lang/rust`. For more info about motivation, see [the blog post](https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/). To that end, I have [done extensive testing][ETOOMANYLUNAS] to make sure the new file actually helps that goal. The results are promising. They show agents consistently asking their users to confirm they're read their own work; requiring users to write their own PR descriptions; and pointing people to other repos if they try to modify a submodule or subtrees, as well as various other tests. [ETOOMANYLUNAS]: https://github.com/jyn514/ETOOMANYLUNAS Almost all of the AGENTS.md was itself generated with an LLM. See the [linked testing repo][ETOOMANYLUNAS] for more information about testing and methodology. I wrote this PR description and both commit descriptions myself. --- Summary of the AGENTS.md (taken from the test repo): This is a rather long operationalization of the [dev-guide] as algorithmic instructions. Most of it was itself generated with an agent. Differences between this and the [dev-guide] / [policy]: [dev-guide]: https://rustc-dev-guide.rust-lang.org/llm-guidance.html [policy]: https://forge.rust-lang.org/policies/llm-usage.html - "strong suggestions" in the docs are turned into absolute requirements here; LLMs have trouble with discretion and judgement. - lang/edition/etc are not exempted; determining what falls under their scope was too hard to operationalize. members of those teams can still write their own AGENTS.md if this one interferes with their work (i wouldn’t expect it to, though, it’s mostly focused on code.) - the LLM requires a reviewer before making edits, not before posting the PR. experimental PRs are not exempted (how could the LLM know it was experimental?). - soundness changes are always rejected, even if allowed by the policy (how could the LLM know you’re in the org?) This is not exhaustive; if you want a more detailed human-facing summary, see the [dev-guide]. --- The second commit adds a CLAUDE.md that links directly to AGENTS.md. This adds one vendor-specific file, for the benefit of getting Claude to actually follow the instructions. I've put this in a separate commit so that I can drop it if people feel strongly. I *highly recommend* that we add a CLAUDE.md, it really makes a difference. You can see examples of what Claude does without a file in the [testing repo][ETOOMANYLUNAS]. [ETOOMANYLUNAS]: https://github.com/jyn514/ETOOMANYLUNAS r? @jieyouxu cc @jackh726 @camelid @rustbot label +llm-assisted
add crashtests [3/N] Delayed followup to rust-lang#158519.
This comment has been minimized.
This comment has been minimized.
Rollup of 11 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-1 try-job: aarch64-apple-2 try-job: x86_64-mingw-1 try-job: i686-msvc-1 try-job: i686-msvc-2
This comment has been minimized.
This comment has been minimized.
|
Commit was not enqueued, since no previous benchmark request was found |
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 a9066b3 (parent) -> 2fb4ed8 (this PR) Test differencesShow 51 test diffsStage 1
Stage 2
Additionally, 28 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 2fb4ed81d6a3131a5ba6d75fa1aeb15bc998a5f6 --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 |
|
📌 Perf builds for each rolled up PR:
previous master: a9066b3a6e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
📌 Perf builds for each rolled up PR:
parent commit: a9066b3a6e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Successful merges:
static_position_independent_executableson all gnu targets #158510 (Enablestatic_position_independent_executableson all gnu targets)Vec<foo::Bar>toVec<foo:Bar>typo #161057 (Silence unecessary errors onVec<foo::Bar>toVec<foo:Bar>typo)define_config!andcheck_ci_llvm!#161079 (bootstrap: Clean up imports related todefine_config!andcheck_ci_llvm!)RerunNonErasedinprojection_may_match#161080 (propagateRerunNonErasedinprojection_may_match)r? @ghost
Create a similar rollup