RFC: add the ability to disable syntax deprecation warnings

[jakebolewski]

Adds the ability to turn off syntax deprecations in the parser with a command line flag --no-depwarn or at runtime:

julia> a = {1,2,3}
WARNING: deprecated syntax "{a,b, ...}".
Use "Any[a,b, ...]" instead.
julia> a = {1,2,3}

WARNING: deprecated syntax "{a,b, ...}".
Use "Any[a,b, ...]" instead.
3-element Array{Any,1}:
 1
 2
 3

julia> Base.syntax_deprecation_warnings(false)
false

julia> a = {1,2,3}
3-element Array{Any,1}:
 1
 2
 3

[ivarne]

Great!
Shouldn't this disable deprecation warnings from @deprecate too?

[ivarne]

Can we add a comment that this mirrors the jl_compileropts_t struct from julia.h

[jakebolewski]

I need to change the names a bit to better reflect that this is only for syntax deprecations.

[ivarne]

Why not add a check in on the compileropts().no_depwarn flag in depwarn, so that it works for @deprecated warnings too.

edit: updated placement suggestion.

[jakebolewski]

Ok I've expanded this to methods as well. I really just need a run time way to turn of syntax deprecation warnings in the frontend, but I could see how turning off method deprecations would be useful.

[ivarne]

I tried to do a small cleanup (no reason to collect the bt if we're not going to warn) if the depwarn funtion in @deprecate in ac0ef2f, but there seems to be a problem with the struct member naming. On the Julia side it is calld no_depwarn, but on the C side it is called depwarn. Which is correct?

[timholy]

👍

[StefanKarpinski]

As I commented on the --noinline option, how about making this --depwarn=[yes|no] so that there's room for potential additional choices in the future?

[jakebolewski]

Ok I've updated with @StefanKarpinski's UI suggestions. I guess the only question now is if it is useful to have this as a runtime or compile time check. A compile time check would remove the performance penalty of deprecated methods, syntax deprecations could still be toggled at runtime.

[ivarne]

This is a great performance improvement for deprecated methods anyway.

[timholy]

I don't have a strong opinion. If there's still some performance hit it will act as encouragement to update the code, which might not be a bad thing. OTOH, I imagine the use case for most people will be "I have some old code that I just need to run to finish this {presentation|paper|grant}, once that's done I'll fix the code"; for them, the ability to toggle inside a session would be irrelevant.

If you don't really care either, then you can take advantage of the new UI and wait for someone who really needs it to add a NO option (stronger than no, removes the check altogether).

[tkelman]

This is failing on appveyor and locally on Win64 due to #9366, it doesn't need to be restarted.