Fix ICE with use clippy::a::b;

[camelid]

Fixes #83317.

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[camelid]

This is inconsistent with the error for use clippy::a;:

error[E0432]: unresolved import `clippy`
 --> src/lib.rs:1:5
  |
1 | use clippy::a;
  |     ^^^^^^ `clippy` is a tool module, not a module

How should I change this code to get that error?

[camelid]

Interestingly, the clippy::a::b error is the same as the error for rustdoc::a::b.

[jyn514]

Right, they're both tool lints.

[camelid]

Before this change clippy::a and rustdoc::a gave different errors, but now they're the same... weird.

[jyn514]

Rustdoc isn't marked as a tool module in resolve: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/question.20about.20tool.20module.20import.20errors

[petrochenkov]

r? @petrochenkov

[petrochenkov]

I think it should be

            PathResult::NonModule(path_res) => {
                if no_ambiguity {
                    assert!(import.imported_module.get().is_none());
                }
                // The error was already reported earlier.
                return None;
            }

Res::Err was used to discern between reachable cases and (seemingly) unreachable cases.

[camelid]

By the way, why do clippy::a and clippy::a::b seem to go through very different code paths? clippy::a didn't trigger the ICE, only clippy::a::b.

[petrochenkov]

Not sure what exactly happens there, but both imports and tool attributes are "special" in some regards.

• Import paths are split into two parts - module (everything except for the last segment, type namespace) and the final segment resolved multiple times in all namespaces.
• Tool attributes are also split into two parts but in a different way - the first segment resolved as a tool module, and all other segments that are not even resolved (because no definitions for them exist in source code), just automatically assumed to be a tool attribute. (Perhaps the implementation is taking a shortcut here and it could be done better, at least for diagnostics.)

When you combine these two special cases together you get some unique code paths.

[petrochenkov]

This is draft because the error is not quite right.

Could you make a different PR for orthogonal diagnostic changes? They may cause a large diff in tests, depending on the scope.
This PR fixes the ICE and that's enough.

[camelid]

This is draft because the error is not quite right.

Could you make a different PR for orthogonal diagnostic changes? They may cause a large diff in tests, depending on the scope.
This PR fixes the ICE and that's enough.

The issue I was talking about is that use clippy::a; and use clippy::a::b; give different errors:

error[E0433]: failed to resolve: maybe a missing crate `clippy`?
  --> $DIR/tool-mod-child.rs:2:5
   |
LL | use clippy::a::b;
   |     ^^^^^^ maybe a missing crate `clippy`?

error[E0432]: unresolved import `clippy`
  --> $DIR/tool-mod-child.rs:1:5
   |
LL | use clippy::a;
   |     ^^^^^^ maybe a missing crate `clippy`?

But if you think the errors are okay, they're fine for me as well.

[petrochenkov]

@bors r+

[bors]

📌 Commit bfae41d has been approved by petrochenkov