[unconventional-import-alias] Fix infinite loop between ICN001 and I002 (ICN001)

[ntBre]

Summary

This fixes the infinite loop reported in #14389 by raising an error to the user about conflicting ICN001 (unconventional-import-alias) and I002 (missing-required-import) configuration options.

Test Plan

Added a CLI integration test reproducing the old behavior and then confirming the fix.

Closes #14389

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Can you tell me about what you tried to do in the configuration and why it didn't work?

[ntBre]

Well, I didn't really try anything exactly. I looked at #14477 that @AlexWaygood sent me as a similar fix, and then I spent some time looking through how configurations are constructed. But #14477 looked like validation on a single configuration field that could be handled during deserialization, while this issue looks to me like it requires validation between two configuration fields (LinterSettings.isort.required_imports and LinterSettings.flake8_import_conventions.aliases), so I didn't think I could handle it in the same way.

Then I found LintConfiguration::as_rule_table, which looked like a possible place to do this kind of validation. I only noticed warnings being emitted earlier, but now I see that it returns a Result. Could I do the validation there and return an Err on this conflict? Or if you have another suggestion I'd be happy to hear it. I should have asked before the PR, but this approach was mentioned in the issue, and it seemed reasonable to me too.

[MichaReiser]

There are a few places where we verify configurations but they all have their trade-offs:

• Inside Configuration::from_options: The main advantage validating options in from_options is that Ruff knows the corresponding configuration file, allowing it to point users directly to which file contains the incorrect configuration. However, from_options is called before combining different configuration file, meaning, it's an incomplete view.
• Inside Configuration::into_settings: into_settings is called after all configuration files were combined. It's where Ruff has a complete view of all settings, but it no longer knows the source of individual setting values.

In your case, Configuration::into_settings is probably the better fit because you need the fully resolved configuration.

[MichaReiser]

Lgtm

Would you mind updating the PR summary to reflect that this is now implemented in the settings

[ntBre]

I updated the PR summary and expanded the error message. Is the new message along the lines of what you had in mind?

[MichaReiser]

Looks good, thanks

[AlexWaygood]

Nice!