Crater rollup#157814
Draft
theemathas wants to merge 33 commits into
Draft
Conversation
…t have a compiler output generated by the lint-docs script
When annotating an item with `#[cfg]` we track both the item that got annotated (with an inert attr) and the names of items that got directly cfg'd out. Extend this mechanism to also work for items within a `cfg_select!`.
Add two lints, very similar to `clippy::useless_conversion`, detecting when `.into()` is being called unnecessarily. We present two separate lints, one that triggers inside of macros, because it is common for macros to have `.into()` calls to make the caller side easier to use. In those cases people should still use the fully-qualified path instead, but allow them to silence that lint without silencing the more general, more likely to be problematic case. This lint allows us to protect developers from the semver-hazard that time 0.3.34 encountered, where a std change caused a valid method chain to start producing inference errors. This is explicitly allowed by the Rust project's backwards compatibility guarantees (inference is not included in them), which means that relying on the blanket `impl Into` is a problem. The lint as implemented has false negatives: because of the way type aliases are handled by the type system, we can't know whether `let _: i32 = 0i32.into()` corresponds to a call on `i32` *or* a call on a type alias that is `i32` only on some platforms (like `#[cfg(..)] type Int = i32;`). To avoid false positives, we keep track of type aliases that have been imported in the local crate and mark their types for exclusion. This means that calling `let _: i32 = Int::into(0i32);` will not be linted against even though it should.
Two things: Since `dbg!` is changing, this removes parts of the file that assumed it expands a certain way. The removed tests will no longer get the "consider borrowing" messages going forward, but I think that's fine; it's unlikely that someone would have hand-written them and the suggestion could easily be wrong in the general case. If we want a more general help message to suggest borrowing in those cases, I think it should be designed as such from the ground up, not targeting `dbg!`. From what I can tell, this test file was intended to be for the "consider borrowing" help messages on diagnostics for `dbg!`. To make it harder to accidentally mess with those messages, I've added checks for them and some comments to clarify intent.
…>` and `[T; N]` They'll be needed for `IntoIterator` impls.
Note: this removes warnings, as this breakage was deemed acceptable, see <rust-lang#124108 (comment)>
Contributor
|
💔 Test for e431ece failed: CI. Failed job:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Contributor
Author
|
@bors try |
This comment has been minimized.
This comment has been minimized.
Contributor
Author
|
@bors try cancel |
Contributor
|
Try build cancelled. Cancelled workflows: |
Contributor
Author
|
@bors try |
This comment has been minimized.
This comment has been minimized.
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) |
Member
remember to also add some mode which is missing from the above: check or run-and-test and the likes |
Contributor
Contributor
Author
|
@craterbot check name=pr-157814-crater-rollup p=4 |
Collaborator
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
This was referenced Jun 12, 2026
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.
r? ghost
Due to the long crater queue, I am making a crater rollup as per @fmease's suggestion. That is, I will run crater of all these PRs together at the same time. And then, once that is finished, I will rerun crater on each individual PR only on the crates that regressed in the result of this crater. This hopefully will speed up the crater process.
PRs in this rollup: #157082, #156749, #153721, #129249, #156977, #157576, #157562, #134021, #157696, #157710