`which("julia")` causes seg fault

[jlapeyre]

problem:

julia> which("julia")

signal (11): Segmentation fault

This should throw an error instead.

Version 1.8.0-DEV.1501 (2022-02-12)

[oscardssmith]

this is a regression since 1.6

[simeonschaub]

@aviatesk You removed the input type annotations in #43087. Is there a way to achieve the same behavior wrt specialization while also keeping the annotations? We could manually throw errors, but that seems cumbersome. Or should we just revert #43087?

[giordano]

@jlapeyre did you mean Sys.which("julia")?

this is a regression since 1.6

In v1.6 it returned a MethodError because he's likely trying to call the wrong function.

[jlapeyre]

Yes, I did mean to say Sys.which("julia"). I tried to call the wrong function, so it should throw an error, not segfault.
It looks like such an obvious mistake that I'm surprised it wasn't found. I guess this is the first issue. I searched for it.

[giordano]

Sure, the segfault isn't nice and should be fixed anyway, but I just want to stress that no working code should be affected by this issues, since which(::String) isn't supposed to work.

[aviatesk]

Is there a way to achieve the same behavior wrt specialization while also keeping the annotations?

After #43113 Julia compiler can inline @nospecialize ::AbstractType signature, so we can reintroduce the input type annotations.
Still I want to keep the current ::Any signature for those utility functions heavily in Core.Compiler (e.g. isbitstype) because isa(t, Type) check inserted by the inliner might involve some cost.
But I agree that the other non-performance sensitive functions like which is better to have input type restrictions.

[jlapeyre]

I just want to stress that no working code should be affected

Oh yes, important distinction.