remove 0.4 syntax and Operators import deprecations

[JeffBezanson]

This removes the remaining 0.4 deprecations.

[tkelman]

Good to bring in the ParseError tests for test/parse.jl from #13054?

# test that pre 0.5 deprecated syntax is a parse error
@test_throws ParseError parse("Int [1,2,3]")
@test_throws ParseError parse("Int [x for x in 1:10]")
@test_throws ParseError parse("foo (x) = x")
@test_throws ParseError parse("foo {T<:Int}(x::T) = x")

@test_throws ParseError parse("Foo .bar")

@test_throws ParseError parse("import x .y")
@test_throws ParseError parse("using x .y")

@test_throws ParseError parse("--x")
@test_throws ParseError parse("stagedfunction foo(x); end")

@test_throws ParseError parse("{1,2,3}")
@test_throws ParseError parse("{1 2 3 4}")
@test_throws ParseError parse("{1,2; 3,4}")
@test_throws ParseError parse("{x for x in 1:10}")
@test_throws ParseError parse("{x=>y for (x,y) in zip([1,2,3],[4,5,6])}")
@test_throws ParseError parse("{:a=>1, :b=>2}")

# this now is parsed as getindex(Pair{Any,Any}, ...)
@test_throws MethodError eval(parse("(Any=>Any)[]"))
@test_throws MethodError eval(parse("(Any=>Any)[:a=>1,:b=>2]"))
@test_throws MethodError eval(parse("(Any=>Any)[x=>y for (x,y) in zip([1,2,3],[4,5,6])]"))

[JeffBezanson]

Yes let's bring those in.

[tkelman]

this probably needs the deprecation for -- to be removed in julia-parser

[tkelman]

Couple dozen newly-failing packages that never updated for these deprecations. It also broke PkgEval until I fixed its Dict syntax but at least that has the excuse that it is still running on all of 0.3, 0.4, and 0.5 and not directly using Compat. A common error will come from BinDeps.@install lines in deps/build.jl -

LoadError: MethodError: no method matching keys(::Array{Pair{Symbol,Symbol},1})
while loading /home/vagrant/.julia/v0.5/Gumbo/deps/build.jl, in expression starting on line 19

[tkelman]

And looks like Lazy.jl was using { } inside macros to mean something else, so maybe we should allow that to be parsed but as a placeholder expression type that throws an error if called?

[MikeInnes]

In general I do think that syntax should be kept as flexible as possible for macros, so it would definitely be nice if the error was deferred. Given MacroTools, it doesn't commit you to a particular representation either.

That said I'll also admit that Lazy.jl didn't have a particularly compelling or important use case for this syntax, it was just using it as a hack to get the @json macro working. So waiting until another use for {...} comes up wouldn't be awful.