Fix @deprecate with the new where syntax

[fredrikekre]

Fix #22030

https://github.com/JuliaLang/julia/pull/22034/files?w=1 for easier reviewing

[StefanKarpinski]

Presumably you've tested this with an actual deprecation using the where syntax and it works? I would suggest adding a test, but we'll start using this as soon as it's merged, which will test it effectively enough.

[fredrikekre]

Actually, it does not quite work for outer constructors (which I forgot about and posted #22033 ). I have an update for that incoming.

[fredrikekre]

Okay, so this now enables signatures with where:

bar(x) = x;
foo(x::T) where T = 1;
@deprecate foo(x::T) where T bar(x);

julia> foo(1)
WARNING: foo(x::T) where T is deprecated, use bar(x) instead.
[...]

and outer constructors:

struct A{T} end
A{T}(x::S) where {T, S} = 1;
@deprecate A{T}(x::S) where {T, S} A{S}();

julia> A{Int}(1.)
WARNING: A{T}(x::S) where {T, S} is deprecated, use A{S}() instead.
[...]

I might as well add some tests, in what file should they go? test/misc.jl seems to be the best match?

[fredrikekre]

On another note, which confused me while fixing this:

julia> f2(x) = 2; f4(x) = 4;

julia> @deprecate f1(x) f2(x);

julia> @deprecate f3(x) f4(x);

julia> f1(1)
WARNING: f1(x) is deprecated, use f2(x) instead.
Stacktrace:
 [1] depwarn(::String, ::Symbol) at ./deprecated.jl:64
 [2] f1(::Int64) at ./deprecated.jl:51
 [3] eval(::Module, ::Any) at ./boot.jl:235
 [4] eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66
 [5] macro expansion at ./REPL.jl:97 [inlined]
 [6] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73
while loading no file, in expression starting on line 0
2

julia> f3(1) # why does this not warn?
4

The call to f3 here should warn? Anyhow, the behaviour is the same pre and post this PR...

[fredrikekre]

I disabled the tests, such that #22043 does not block this PR. The tests pass locally one by one.

[tkelman]

Can't these be @test_broken ?

[fredrikekre]

There is not @test_warn_broken though. On another note, when these are activated we should make sure that Base.JLOptions().depwarn is turned on before running that testset.

[tkelman]

tests for deprecations should probably be done in a separate process where we can be sure to run it with each possible value of the depwarn flag and check that the behavior is right for each value