Rollup of 11 pull requests - #161092
Closed
JonathanBrouwer wants to merge 37 commits into
Closed
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`.
…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
…unsigned-bound, r=clarfonthey Optimize offset_from_unsigned result bounds Hint that result cannot be larger than isize max
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
…jieyouxu Silence unecessary errors on `Vec<foo::Bar>` to `Vec<foo:Bar>` typo When encountering a type path with a bound constraint instead of a type path and the bound type isn't resolved, only emit the resolve error, as that has an appropriate suggestion. This cuts down the verbosity of a relatively normal typo. Fix rust-lang#92685.
bootstrap: Clean up imports related to `define_config!` and `check_ci_llvm!` This PR takes the two macros defined in `core/config/mod.rs`, moves them to their own module, and adjusts all callers to import the macros from that module instead of from the crate root. This lets us remove `#[macro_export]` from the macro declarations. Along the way, we also adjust `define_config!` to use more fully-qualified paths, so that callers don't have to add several mysterious imports in order to compile. --- (Because macro-rules have weird namespacing by default, it's usually a good idea to isolate them in their own module, and then write `pub(use)` below to pull them into the normal name-resolution system.) There should be no change to bootstrap's behaviour.
…-no-eased-handling, r=lcnr propagate `RerunNonErased` in `projection_may_match` `projection_may_match` treated `RerunNonErased` same as `NoSolution`, ICE'ing later in path instead of rerunning goal in original typing mode. Fixes rust-lang#159462 rust-lang#159457 r? lcnr
…bzol bootstrap: Restrict the normalization of relative paths This is my follow-up to rust-lang#160970 (comment), which should hopefully retain the fixed behaviour for argument beginning with `./` while avoiding some undesirable side-effects. In particular, I want to avoid ever modifying command-line arguments unless they specifically match the two patterns we're trying to account for: absolute paths, and relative paths beginning with an explicit `./`. I also want to specifically avoid modifying arguments unless we can demonstrate that they correspond to a file that exists. For example, we shouldn't be accepting paths like `./tidyselftest` or `./mir-opt`, because those arguments don't actually make sense as paths relative to the source root. r? Kobzol
add crashtests [3/N] Delayed followup to rust-lang#158519.
rustbot
added
A-LLVM
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
⌛ Trying commit 2f93a8d with merge 67f2613… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/31798906876 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 14, 2026
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
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #161063, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
Contributor
Author
|
@bors try cancel |
rustbot
removed
the
S-waiting-on-author
Contributor
|
Try build cancelled. Cancelled workflows: |
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
13 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:
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