fix [std_instead_of_core]: false positive for multi-imports by bushrat011899 · Pull Request #17252 · rust-lang/rust-clippy

bushrat011899 · 2026-06-15T13:09:49Z

Objective

Fix false positive identified in this comment on fix [std_instead_of_core]: false positives for core::io/MSRV #16964.
Fixes std_instead_of_core creates an invalid fix on stacked imports #12468
Addresses this comment

Solution

The current version of this lint can improperly trigger a suggestion for certain complex use statements. This PR attempts to resolve this by directly tracking each segment in a path to ensure no items are inadvertently marked as std_instead_of_core/etc.

This problem is exacerbated by #16964 if/when it is merged, as unstable items will be correctly excluded from the lint on their own, but included when a part of a multi-import statement.

Notes

No AI tooling of any kind was used during the creation of this PR.
Originally a part of fix [std_instead_of_core]: false positives for core::io/MSRV #16964, but has been split off for ease of review. Either PR can be merged first.

Please write a short comment explaining your change (or "none" for internal only changes)

changelog: fix certain false positives for [std_instead_of_core] for mulit-imports.

rustbot · 2026-06-15T13:09:55Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @llogiq (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: 8 candidates
8 candidates expanded to 8 candidates
Random selection from Jarcho, dswij, llogiq, samueltardieu

github-actions · 2026-06-15T13:20:33Z

Lintcheck changes for 5e134b4

Lint	Added	Removed	Changed
`clippy::std_instead_of_alloc`	3	1	65
`clippy::std_instead_of_core`	9	4	4

This comment will be updated if you push new changes

rustbot · 2026-06-15T14:21:20Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Jarcho · 2026-06-15T17:38:37Z

r? Jarcho

bushrat011899

A few comments that might be relevant for reviewers!

View changes since this review

rustbot · 2026-06-16T12:36:13Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

…li-obk Fix(ICE): Remove `unwrap` from `get_module_children` # Objective Fix an ICE I ran into while developing rust-lang/rust-clippy#17252 that stems from `rustc_metadata::rmeta::decoder::CrateMetadata::get_module_children` calling `unwrap`. The local value `non_reexports` can be `None` when the passed in `DefIndex` is for a non-module-like item. The documentation for `get_module_children` *implies* that it must only be called with module-like item indices, however it seems to me that it would be appropriate to just return nothing when called on a non-module-like item (if it isn't module-like, it has zero children). ## Solution - Switched from an `Option::unwrap` to an `if let Some(...)` --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.E2.9C.94.20.60rustc.60.20ICE.20from.20.60TyCtxt.3A.3Amodule_children.60/with/603700184) for some discussion. * Please see this [failed Clippy CI run](https://github.com/rust-lang/rust-clippy/actions/runs/27596428127/job/81587609898#step:5:1) for an example of the ICE caused.

…etrochenkov,oli-obk Replace `unwrap` with `expect` in `get_module_children` # Objective I ran into an ICE I ran into while developing rust-lang/rust-clippy#17252 that stems from `rustc_metadata::rmeta::decoder::CrateMetadata::get_module_children` calling `unwrap`. The local value `non_reexports` can be `None` when the passed in `DefIndex` is for a non-module-like item. The documentation for `get_module_children` *implies* that it must only be called with module-like item indices, however the use of `unwrap` makes diagnosing the ICE trickier than it has to be. Additionally, this behaviour is not documented on `TyCtxt::module_children`. ## Solution - Switched from an `Option::unwrap` to a `Option::expect` - Added panic documentation to `get_module_children` - Replicated documentation for `TyCtxt::module_children` --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.E2.9C.94.20.60rustc.60.20ICE.20from.20.60TyCtxt.3A.3Amodule_children.60/with/603700184) for some discussion. * Please see this [failed Clippy CI run](https://github.com/rust-lang/rust-clippy/actions/runs/27596428127/job/81587609898#step:5:1) for an example of the ICE caused.

…unwrap, r=petrochenkov,oli-obk Replace `unwrap` with `expect` in `get_module_children` # Objective I ran into an ICE I ran into while developing rust-lang/rust-clippy#17252 that stems from `rustc_metadata::rmeta::decoder::CrateMetadata::get_module_children` calling `unwrap`. The local value `non_reexports` can be `None` when the passed in `DefIndex` is for a non-module-like item. The documentation for `get_module_children` *implies* that it must only be called with module-like item indices, however the use of `unwrap` makes diagnosing the ICE trickier than it has to be. Additionally, this behaviour is not documented on `TyCtxt::module_children`. ## Solution - Switched from an `Option::unwrap` to a `Option::expect` - Added panic documentation to `get_module_children` - Replicated documentation for `TyCtxt::module_children` --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.E2.9C.94.20.60rustc.60.20ICE.20from.20.60TyCtxt.3A.3Amodule_children.60/with/603700184) for some discussion. * Please see this [failed Clippy CI run](https://github.com/rust-lang/rust-clippy/actions/runs/27596428127/job/81587609898#step:5:1) for an example of the ICE caused.

Rollup merge of #158002 - bushrat011899:get_module_children_unwrap, r=petrochenkov,oli-obk Replace `unwrap` with `expect` in `get_module_children` # Objective I ran into an ICE I ran into while developing rust-lang/rust-clippy#17252 that stems from `rustc_metadata::rmeta::decoder::CrateMetadata::get_module_children` calling `unwrap`. The local value `non_reexports` can be `None` when the passed in `DefIndex` is for a non-module-like item. The documentation for `get_module_children` *implies* that it must only be called with module-like item indices, however the use of `unwrap` makes diagnosing the ICE trickier than it has to be. Additionally, this behaviour is not documented on `TyCtxt::module_children`. ## Solution - Switched from an `Option::unwrap` to a `Option::expect` - Added panic documentation to `get_module_children` - Replicated documentation for `TyCtxt::module_children` --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.E2.9C.94.20.60rustc.60.20ICE.20from.20.60TyCtxt.3A.3Amodule_children.60/with/603700184) for some discussion. * Please see this [failed Clippy CI run](https://github.com/rust-lang/rust-clippy/actions/runs/27596428127/job/81587609898#step:5:1) for an example of the ICE caused.

bushrat011899 · 2026-06-23T01:25:01Z

-            && is_stable(cx, def_id, self.msrv)
            && !path.span.in_external_macro(cx.sess().source_map())
            && !is_from_proc_macro(cx, &first_segment.ident)
            && !matches!(def_kind, DefKind::Macro(_))


Suggested change

&& !matches!(def_kind, DefKind::Macro(_))

This PR can be trivially modified/followed-up to resolve #17260. This is because emit_lints has been modified to explicitly handle multiple items being resolved from the same path by taking the intersection of availabilities.

View changes since the review

bushrat011899 · 2026-06-23T01:27:18Z

+        for &span in span.primary_spans() {
+            span_lint_and_help(
+                cx,
+                lint,
+                span,
+                format!("used import from `{used_mod}` instead of `{replace_with}`"),
+                None,
+                format!("consider importing the item from `{replace_with}`"),
+            );
+        }


Suggested change

for &span in span.primary_spans() {

span_lint_and_help(

cx,

lint,

span,

format!("used import from `{used_mod}` instead of `{replace_with}`"),

None,

format!("consider importing the item from `{replace_with}`"),

);

}

span_lint_and_help(

cx,

lint,

span,

format!("used import from `{used_mod}` instead of `{replace_with}`"),

None,

format!("consider importing the item from `{replace_with}`"),

);

This PR can be trivially modified/followed-up to resolve #17261, since the required multispans are already being computed.

View changes since the review

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jun 15, 2026

rustbot assigned llogiq Jun 15, 2026

bushrat011899 mentioned this pull request Jun 15, 2026

fix [std_instead_of_core]: false positives for core::io/MSRV #16964

Merged

bushrat011899 force-pushed the std_instead_of_core_multi_imports branch 4 times, most recently from db1918a to 5dc77a7 Compare June 15, 2026 14:15

bushrat011899 commented Jun 15, 2026

View reviewed changes

Comment thread tests/ui/std_instead_of_core_unfixable.rs

rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jun 15, 2026

rustbot assigned Jarcho and unassigned llogiq Jun 15, 2026

bushrat011899 force-pushed the std_instead_of_core_multi_imports branch 5 times, most recently from 3885b82 to 2eda7d5 Compare June 16, 2026 11:07

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Jun 16, 2026

bushrat011899 commented Jun 16, 2026

View reviewed changes

Comment thread clippy_lints/src/std_instead_of_core.rs

Comment thread clippy_lints/src/std_instead_of_core.rs Outdated

This comment has been minimized.

Sign in to view

bushrat011899 force-pushed the std_instead_of_core_multi_imports branch from 2eda7d5 to 98e1658 Compare June 16, 2026 12:36

bushrat011899 mentioned this pull request Jun 17, 2026

Replace unwrap with expect in get_module_children rust-lang/rust#158002

Merged

bushrat011899 force-pushed the std_instead_of_core_multi_imports branch from 98e1658 to 130da4a Compare June 18, 2026 01:19

bushrat011899 force-pushed the std_instead_of_core_multi_imports branch from 130da4a to 28d43c3 Compare June 18, 2026 01:39

This was referenced Jun 18, 2026

std_instead_of_core/etc. miss macros #17260

Open

std_instead_of_core/etc. should emit MultiLine help messages #17261

Open

fix: [std_instead_of_core] false positive for multi-imports

5e134b4

bushrat011899 force-pushed the std_instead_of_core_multi_imports branch from 28d43c3 to 5e134b4 Compare June 23, 2026 01:13

bushrat011899 commented Jun 23, 2026

View reviewed changes

This was referenced Jun 23, 2026

fix [std_instead_of_core]: don't assume alloc/core are in the extern prelude #17296

Open

fix [std_instead_of_core]: false negative for non-FQ paths #17303

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix [std_instead_of_core]: false positive for multi-imports#17252

fix [std_instead_of_core]: false positive for multi-imports#17252
bushrat011899 wants to merge 1 commit into
rust-lang:masterfrom
bushrat011899:std_instead_of_core_multi_imports

bushrat011899 commented Jun 15, 2026 •

edited

Loading

Uh oh!

rustbot commented Jun 15, 2026

Uh oh!

github-actions Bot commented Jun 15, 2026 •

edited

Loading

Uh oh!

Uh oh!

rustbot commented Jun 15, 2026

Uh oh!

Jarcho commented Jun 15, 2026

Uh oh!

bushrat011899 left a comment •

edited by rustbot

Loading

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jun 16, 2026

Uh oh!

bushrat011899 Jun 23, 2026 •

edited by rustbot

Loading

Uh oh!

bushrat011899 Jun 23, 2026 •

edited by rustbot

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

bushrat011899 commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Notes

Uh oh!

rustbot commented Jun 15, 2026

Uh oh!

github-actions Bot commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

rustbot commented Jun 15, 2026

Uh oh!

Jarcho commented Jun 15, 2026

Uh oh!

bushrat011899 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jun 16, 2026

Uh oh!

bushrat011899 Jun 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bushrat011899 Jun 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bushrat011899 commented Jun 15, 2026 •

edited

Loading

github-actions Bot commented Jun 15, 2026 •

edited

Loading

bushrat011899 left a comment •

edited by rustbot

Loading

bushrat011899 Jun 23, 2026 •

edited by rustbot

Loading

bushrat011899 Jun 23, 2026 •

edited by rustbot

Loading