Could we move this check inside the rule itself so we don't have to duplicate it? This feels surprising to me, but I tried removing them locally and they're obviously needed somewhere to avoid duplicate diagnostics, as the comment says.

I suppose we could. I was just trying to be consistent with what I saw in the code-base. Just a few lines above there's

// Avoid duplicate checks if the parent is a union, since these rules already
// traverse nested unions.
if !checker.semantic.in_nested_union() {

Fair enough!

I think I'm not as against passing bare bool arguments as most people, but if you really want to avoid it, I think the more typical approach is defining a two-variant enum. Maybe something like this:

enum TraverseOptions {
    Yes,
    No,
}

As an even smaller nit here, I think we usually put the docs above the #[derive].

I went with the struct as it's easier to extend should the need for more config options arise in the future. If you'd rather have it an enum, I'm also fine with that. I just find bare bool arguments hard to read at call sites, so I try to avoid them unless the function name gives a strong clue as to what the flag does.

Should I change it anyway?

Are there more options you think might be needed? I guess I was assuming this would be the only one.

In any case, I don't feel too strongly about this, so we can just move ahead with the current version.

I was a bit skeptical about this transformation in #18508 (comment) but if you and @AlexWaygood think it's fine, I'm happy with it. I just thought it was likely to be a separate mistake that a safe autofix could hide.

This might become hard to track, but how about making the fix unsafe if both

1. An Optional was visited
2. None is (one of) the redundant types in the union

I guess it's fine if it would complicate the code, again I don't feel too strongly. And the change is in preview, so we can collect some feedback here.

Are there more options you think might be needed? I guess I was assuming this would be the only one.

In any case, I don't feel too strongly about this, so we can just move ahead with the current version.

I guess it's fine if it would complicate the code, again I don't feel too strongly. And the change is in preview, so we can collect some feedback here.

Fair enough!