type mismatch at src/crystal/main.cr

[HOMODELUNA]

type mismatch at main.cr

in src/crystal/main.cr

  def self.main(&block)
    GC.init

    status =
      begin
        yield
        0
      rescue ex
        1
      end

    exit(status, ex)
  end

here in exit(status, ex) , ex is an Exception ,so it can't be the parameter of self.exit(status : Int32, exception : Exception?) : Int32.this error occurs when I tried to build scry on windows.

It needs a reinterpret cast, it works after I added that cast:

  def self.main(&block)
    GC.init

    status =
      begin
        yield
        0
      rescue ex
        1
      end

    exit(status, ex.as(Exception | ::Nil))
  end

[HertzDevil]

An Exception is an Exception? though. What does the actual error look like?

[HOMODELUNA]

@HertzDevil The actual error is:

PS E:\lang\Crystal\scry-language-server> shards build --release --static
Dependencies are satisfied
Building: scry
Error target scry failed to compile:
Showing last frame. Use --error-trace for full trace.

In E:\lang\Crystal\src\crystal\main.cr:45:5

 45 | exit(status, ex)
      ^---
Error: no overload matches 'Crystal.exit' with types Int32, (Exception | Nil)

Overloads are:
 - Crystal.exit(status : Int32, exception : Exception | ::Nil)
Couldn't find overloads for these types:
 - Crystal.exit(status : Int32, exception : Exception)

[HertzDevil]

Duplicate of crystal-lang-tools/scry#186. It seems it might have happened because Exception here refers to Crystal::Exception, but the same class in the Crystal compiler has been renamed to Crystal::CodeError in #10197.

The only thing we can probably do is use the fully qualified type names for every def in error messages like this.

[straight-shoota]

Ooh, to my knowledge that's the first instance of a problem caused by the fact that the Crystal namespace is shared between the stdlib runtime and the compiler. If they were different namespaces, it probably would've been more clear because CrystalCompiler::Exception would've never matched for Exception in the Crystal namespace.

I'm split about fully qualified type names. It sure makes sense to be most specific. But it also adds a lot of noise to the already pretty crowded overload listings. Perhaps we could identify cases where the shortened types could be ambiguous and print fully qualified names there?