static_show: Print primitive types with Base.reinterpret(...)

[topolarity]

before:

julia> ccall(:jl_, Cvoid, (Any,), Char('u'))
Char(0x75000000)

after:

julia> ccall(:jl_, Cvoid, (Any,), Char('u'))
reinterpret(Char, 0x75000000)

I know that @vtjnash has advocated for us to provide a custom de-serializer, but I think the mental burden for users to have to worry about types that look eval-able (and frequently are) but in practice need a custom de-serializer is too much.

[vtjnash]

I really dislike the implication here that a printed Char is an instance of the reinterpret struct. This introduces an ambiguity into our serialization format which I don't think is a good idea

[topolarity]

I can spell this as Base.reinterpret - the ambiguity is no worse than resolving any other TypeName IMO.

[vtjnash]

Both of those mean you have an instance of the reinterpret struct for debugging, which is not what it means

[topolarity]

Both of those mean you have an instance of the reinterpret struct for debugging, which is not what it means

This PR is changing that definition

[JeffBezanson]

It sounds like we have not decided whether to print an eval-able (or close to it) expression here or use a different new text-based serialization format.

[topolarity]

It sounds like we have not decided whether to print an eval-able (or close to it) expression here or use a different new text-based serialization format.

Yeah.. I think the heart of the conflict is whether we have a precise serialization (i.e. recoverable to an exact type) and then imprecise de-serialization (i.e. guesstimate when picking a 'close enough' type to map back to as a pre-compile hint), or if we instead have an imprecise serializer to begin with (that throws out / approximates type information before it even gets to --trace-compile)

I feel that we lose a lot of valuable introspection when --trace-compile starts to lie / approximate types for you, so I would really like to do the first thing and have something that can serialize / print a type for the user exactly.

The imprecise version just seems like it's asking for a ton of confusion when it comes time to investigate unexpected compilation, etc.

[vtjnash]

Yes, exactly why I think this PR is bad, since it implies that our serializer is no longer intended to be a correct and precise output, but is rather that there are supposed to be various arbitrary heuristics during (de)serialization to guess what calling various random functions in various random packages (such as Pkg.reinterpret) do when executed or constructed

[topolarity]

Yes, exactly why I think this PR is bad, since it implies that our serializer is no longer intended to be a correct and precise output, but is rather that there are supposed to be various arbitrary heuristics during (de)serialization to guess what calling various random functions in various random packages (such as Pkg.reinterpret) do when executed or constructed

That's an exaggeration IMO

It reserves exactly one fully-qualified (non-)typename Base.reinterpret to have special meaning in the serializer / de-serializer.