(I'm halfway to eliminating those untagged values from codegen in https://github.com/JuliaLang/julia/pull/11973)
On Mon, Jul 20, 2015 at 11:27 AM Stefan Karpinski <[email protected]> wrote: > Personally, I always explicitly unbox and box when using intrinsics. I > kind of don't care for the auto-un/boxing since it's not clear when it is > optional. I'd prefer to just raise clear errors when someone gets it wrong > in a way that can be checked, but Jeff implemented the auto-un/boxing and > may have strong feelings about it. > > On Sat, Jul 18, 2015 at 8:46 PM, Jameson Nash <[email protected]> wrote: > >> Intrinsics.sitofp doesn't have a return type. It needs to be wrapped by a >> call to Intrinsics.box to actually get a return type assigned. There are a >> few places (such as sitofp) where the expr type doesn't matter, so type >> inference doesn't bother marking them. Unfortunately, code_warntype doesn't >> know that, so it highlights those places anyways. >> >> >> On Sat, Jul 18, 2015 at 8:39 PM <[email protected]> wrote: >> >>> I have developed a parameterized type called SortedDict, and a version >>> of the code recently developed is generating type warnings; I can't figure >>> out why. The type SortedDict is parameterized by K (key type), D (data >>> type) and Ord (ordering). Let s be of type SortedDict(ASCIIString, Float64, >>> Forward). >>> >>> The following snippet is generating a type warning when checked with >>> @code_warntype setindex1(s, 5, "c") >>> >>> function setindex1{K, D, Ord <: Ordering}(m::SortedDict{K,D,Ord}, d_, k_) >>> insert!(m.bt, convert(K,k_), convert(D,d_), false) >>> end >>> >>> on a call to Base.sitopf. As far as I know, this is a new problem >>> (i.e., did not exist in previous versions of 0.4) Shouldn't the compiler >>> know that the result of Base.sitopf is of type Float64? >>> >>> >>> Meanwhile, the following snippet, which I thought would be equivalent, >>> is generating four type warning (according to @code_warntype setindex2(s, >>> 5, "c"): one on each 'convert' invocation and one on the invocations of >>> keytype and datatype each: >>> >>> @inline keytype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = K >>> @inline datatype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = D >>> >>> function setindex2(m::SortedDict, d_, k_) >>> insert!(m.bt, convert(keytype(m),k_), convert(datatype(m),d_), >>> false) >>> end >>> >>> This is in Julia 0.4, 6-day-old master. Why is the type inferencing not >>> working as I would have expected? >>> >>> Thanks, >>> Steve Vavasis >>> >>> >
