Allow literal bitstype and symbol type parameters

[mbauman]

Since Julia now allows these, we should, too. Before:

julia> using HDF5, JLD
       type Foo{a}; end
       immutable Bar; x::Int; end

julia> save("test.jld", "x", Foo{:x}()); load("test.jld")
WARNING: type Foo{x} not present in workspace; reconstructing
Dict{Union(UTF8String,ASCIIString),Any} with 1 entry:
  "x" => ##Foo{x}#9613()

julia> save("test.jld", "x", Foo{1.0}()); load("test.jld")
ERROR: `is_valid_type_ex` has no method matching is_valid_type_ex(::Float64)
 in map at ./base.jl:189
 in is_valid_type_ex at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:753
 in julia_type at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:772
 in _julia_type at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:763
 in julia_type at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:17
 in jldatatype at /Users/mbauman/.julia/v0.3/HDF5/src/jld_types.jl:612
 in read at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:331
 in read at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:316
 in anonymous at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:977
 in jldopen at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:237
 in load at /Users/mbauman/.julia/v0.3/HDF5/src/JLD.jl:976

julia> save("test.jld", "x", Foo{Bar(1)}); load("test.jld")
WARNING: type Foo{Bar(1)} not present in workspace; reconstructing
Dict{Union(UTF8String,ASCIIString),Any} with 1 entry:
  "x" => ##Foo{Bar(1)}#9675()

After:

julia> save("test.jld", "x", Foo{:x}()); load("test.jld")
Dict{Union(UTF8String,ASCIIString),Any} with 1 entry:
  "x" => Foo{:x}()

julia> save("test.jld", "x", Foo{1.0}()); load("test.jld")
Dict{Union(UTF8String,ASCIIString),Any} with 1 entry:
  "x" => Foo{1.0}()

julia> save("test.jld", "x", Foo{Bar(1)}); load("test.jld") # Edited; this is still unsupported
WARNING: type Foo{Bar(1)} not present in workspace; reconstructing
Dict{Union(UTF8String,ASCIIString),Any} with 1 entry:
  "x" => ##Foo{Bar(1)}#9675()

[mbauman]

It's a little unfortunate that we can't be more specific here, but there's no way to determine if calling a symbol might end up as a bitstype immutable without trying it.

[coveralls]

Coverage increased (+0.01%) when pulling 33d9991 on mb/bitstypes into 2237628 on master.

[simonster]

Hmm. It seems like this introduces a potential security vulnerability. Using eval already gives me the creeps, but previously we had some safeguards since we only allowed Union and TypeVar calls. If we allow arbitrary call expressions, one can create a JLD file with a type like Val{rm("C:\\"; recursive=true)} and then get someone to load it. There's also no guarantee that calling print on an arbitrary bits type immutable gives you an expression that can be used to reconstruct it, since it might have its own print method or an inner constructor, and on Julia 0.3 print won't print the full path to the module in which the immutable is defined. It seems that we either need to serialize the types/type parameters using JLD or come up with our own string representation of types that can be used to reconstruct them.

[mbauman]

Yeah, agreed. It gave me the heebie-jeebies, too, which is why I left that inline note. The rest of this is simple enough (and likely covers the vast majority of use-cases) that I say we merge this and punt the non-literal immutable problem to another issue.

[coveralls]

Coverage increased (+0.01%) when pulling 5c7db4d on mb/bitstypes into 2237628 on master.

[timholy]

I don't have any concerns to add (good catch on the eval risks), and I see you've re-restricted it. I'll let the two of you decide if/when to merge (AppVeyor failure seems to be a network problem, nothing to do with your code).

[mbauman]

I think this is a simple step in the right direction, so I hit the button. I opened issue #204 to address the custom immutable problem.

[simonster]

Yes, I agree that this is a strict improvement. For the moment, we might want to throw an error when saving types parametrized by bits types that we can't read.

[timholy]

+1 for the error upon save.

[tkelman]

Every version of HDF5 released since this was merged needs to update its minimum supported julia version in REQUIRE. This broke HDF5 and MAT on a colleague's machine who was still using 0.3.2.

[mbauman]

Yikes, I'm sorry about that, Tony. I'll be sure to think about things like this in the future. Thanks for taking care of the REQUIRE changes.

[tkelman]

It was just the one version, right? That's what it looked like in metadata. It would be a bit more convenient for searching and navigation if recent tags of the package were showing up in the github repo here.

[timholy]

Ouch. Sorry about that. Many thanks for discovering and fixing the problem.

[timholy]

Are tags not showing up in checkouts? I have most of them, but I wonder if bypassing Pkg.publish() fails to send out the tags to the rest of the world?

[simonster]

If you don't use Pkg.publish(), I believe you have to run git push --tags to push the tags to package repository.