Add default --warn-overwrite=default for cross-module warnings

[PatrickHaecker]

Add a third mode autodefault to --warn-overwrite and make it the default. In default mode, method overwrite warnings are only shown when they are likely a problem. Currently this means they are shown when the new definition comes from a different module than the original. In this situation, precompilation would error, so warning about it in interactive use gives users early feedback. Precompilation also errors when the redefinition is in the same module, but warning on this, too (as in --warn-overwrite=yes), is noisy for the common case of re-evaluating code within the same module.

--warn-overwrite=yes and --warn-overwrite=no retain their existing behavior (warn on all overwrites or none, respectively). Anonymous function overwrites continue to always warn regardless of the setting. We keep --warn-overwrite=yes for cases where it is clearly beneficial like creating the sysimage.

Previous work with discussions: #23002 and #23030.

This implements the idea first proposed by @martinholters in the discussion and uses default as defined by triage.

Partly fixes #61388

This PR was created with support from Claude Opus 4.6 and 4.7.

[Keno]

auto doesn't strike me as particularly descriptive

[PatrickHaecker]

Thanks for having a look.
This is a compromise I wasn't too happy with, too. It follows the symmetry with --check-bounds, --color and the like and would have the advantage (with a proper wording, which I probably don't have here), that we could adjust the rules slightly when we learn something while keeping the CLI value being auto.

What about crossmod? Would that work for you, @Keno?

[fingolfin]

Maybe foreign? external? outside?

[PatrickHaecker]

Thanks! I think all (now 5) proposals are good if you know what what they are doing, but I fear none of them are self-explanatory. I do not have any preference here. If anyone has a favorite, please tell me, so I'll change to it.
Or is triage interested in bikeshedding naming? :-)

[JeffBezanson]

👍 From triage. We think auto suggests that it automatically picks either yes or no, which is not what it does. We think it can be called default, suitably vague so that we can possibly change the heuristic used in the future.

[JeffBezanson]

We should also make sure this is not causing tons of spurious warnings in CI or elsewhere.

[JeffBezanson]

OK this does surface a couple warnings in CI, some of which are intentional overwrites, so we will need to silence some cases and maybe fix others.

[PatrickHaecker]

OK this does surface a couple warnings in CI, some of which are intentional overwrites, so we will need to silence some cases and maybe fix others.

I am on a voyage to silence the CI warnings.

The original idea was to always warn when redefining a method except when it happens in the same module to avoid warnings when using the REPL.

However, this produces a lot of warnings, especially when redefining a module, e.g. by reincludeing a file with a module definition. The reason is that

module A end; a = A; module A end; a == A

returns false as the module identity changes when redefining a module. Therefore, the modules' name should be compared. However, as two identically named submodules can have totally different parent modules, the fully qualified name of the modules should actually be compared.

Except that we have some possibly questionable use of some macros like @deprecate or repositories where the same file is included in a module and its submodule. You can argue that overwriting a method from a submodule or from a parent module is at least something where the author is in full control similar to overwrites in a module. Therefore, at least to limit the number of warnings this change will generate, but possibly because it makes sense, do not warn in these cases.

Combining everything means we should only warn if the FQN of one module is not a prefix of the other's module.

Now we still have some issues in Julia itself and then it would be interesting to see what Pkgeval brings up. I am still pretty sure that something like this is a good idea. I am less convinced that we can activate it as default without creating too much effort in the ecosystem. But we'll see.

[PatrickHaecker]

With the PR for SparseArrays.jl I think Julia itself does not have additional warnings due to this PR (but I am not sure, so if anyone knows a method where the result is a reliable number of overall warnings during building and testing, I am all ear).

As you @fingolfin seem to be interested in this feature, could you please trigger @nanosoldier runtests() and @nanosoldier runbenchmarks() on this PR? It would be interesting to see how many additional warnings this will produce in the ecosystem and whether the additional logic in method_overwrite makes something slower.