RFC: add the ability to disable syntax deprecation warnings #9294

Merged
merged 1 commit into from Dec 15, 2014

Projects

None yet

5 participants

@jakebolewski
Member

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
Contributor
ivarne commented Dec 10, 2014

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

@ivarne ivarne commented on an outdated diff Dec 10, 2014
@@ -241,3 +241,18 @@ end
warn(err::Exception; prefix="ERROR: ", kw...) =
warn(sprint(io->showerror(io,err)), prefix=prefix; kw...)
+
+# Julia compiler options struct
@ivarne
ivarne Dec 10, 2014 Contributor

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

@jakebolewski
Member

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

@ivarne
Contributor
ivarne commented Dec 10, 2014

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
Member

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
Contributor
ivarne commented Dec 11, 2014

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
Member
timholy commented Dec 14, 2014

👍

@StefanKarpinski
Member

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
Member

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.

@jakebolewski jakebolewski Add the ability to disable deprecation warnings with a cmd line switch
The `--depwarn={yes|no}` flag turns on/off method warnings and deprecated syntax warnings
in the parser.

(unexported) `compileropts()` method added to retrieve the
compileropts struct from libjulia.

(unexported) `syntax_deprecation_warnings(::Bool)` method added to
turn off syntax deprecation warnings in the parser at runtime.
the method returns the previous syntax deprecation warning state.

add NEWS entry and update docs for command line switches
4d38dc3
@ivarne
Contributor
ivarne commented Dec 15, 2014

This is a great performance improvement for deprecated methods anyway.

@timholy
Member
timholy commented Dec 15, 2014

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
Member
tkelman commented Dec 15, 2014

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

@jakebolewski jakebolewski merged commit e93672d into master Dec 15, 2014

1 of 2 checks passed

continuous-integration/appveyor AppVeyor build failed
Details
continuous-integration/travis-ci The Travis CI build passed
Details
@ivarne ivarne deleted the jcb/nodepwarn branch Dec 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment