INPUT-ERROR-IN-COMPILED-FILE not subclass of SERIOUS-CONDITION

[Samium Gromoff]

A look at READ-FOR-COMPILE-FILE in src/c/main.lisp uncovers that conditions
of type INPUT-ERROR-IN-COMPILED-FILE are signalled using ERROR.

Looking at the definition of INPUT-ERROR-IN-COMPILED-FILE uncovers that
it's a FATAL-COMPILER-ERROR, which in turn is an ENCAPSULATED-CONDITION.

A consequence of this is that handling SERIOUS-CONDITIONs won't
prevent one from falling out into the debugger, which sounds rather
undesirable.

Looking around uncovers the following snippet from a comment by Christophe:

> ... [ Note: we don't make
> ;;; COMPILER-ERROR inherit from SERIOUS-CONDITION, because
> ;;; conventionally SERIOUS-CONDITIONs, if unhandled, end up in the
> ;;; debugger; although the COMPILER-ERROR might well trigger an entry
> ;;; into the debugger, it won't be the COMPILER-ERROR itself that is
> ;;; the direct cause. ]

Now, the issue suddenly looks more complicated and seems to require more
context from my side.

Essentially, I want to programmatically handle cases like this:

debugger invoked on a SB-C::INPUT-ERROR-IN-COMPILE-FILE in thread #<THREAD "initial thread" RUNNING {10029D7091}>:
  READ failure in COMPILE-FILE:
    SB-INT:SIMPLE-READER-PACKAGE-ERROR at 1798 (line 36, column 42) on #<SB-SYS:FD-STREAM for "file /little/home/empty/desr/git/graphic-forms/graphic-forms-tests.asd" {100475F921}>:
      package "GFSYS" not found
[snip]
0: (SB-C::READ-FOR-COMPILE-FILE
    #<SB-SYS:FD-STREAM for "file /little/home/empty/desr/git/graphic-forms/graphic-forms-tests.asd" {100475F921}>
    0)
1: (SB-FASL::LOAD-AS-SOURCE
    #<SB-SYS:FD-STREAM for "file /little/home/empty/desr/git/graphic-forms/graphic-forms-tests.asd" {100475F921}>
    NIL
    NIL)
2: ((FLET SB-FASL::LOAD-STREAM)
    #<SB-SYS:FD-STREAM for "file /little/home/empty/desr/git/graphic-forms/graphic-forms-tests.asd" {100475F921}>
    NIL)
3: (LOAD #P"/home/empty/desr/git/.asdf-registry/graphic-forms-tests.asd")[:EXTERNAL]
4: (FIND-SYSTEM "graphic-forms-tests" T)

In the end, I'm not sure what to make of it, but in this light it
at least looks like SBCL could've been more cooperative.

[Attila Lendvai (attila-lendvai)]

on a related note: if the output of a fasl fails (e.g. out of memory), and the half-written fasl is later read by SBCL, then an end-of-file error comes out from the fasl parsing code.

[Nikodemus Siivola (nikodemus)]

 status confirmed
 tag compiler reader
 importance medium

INPUT-ERROR-IN-COMPILED-FILE should probably not be a COMPILER-ERROR at all.

Re. truncated fasls: aside from SBCL dying without unwinding its own stack an incomplete fasl should be considered a bug these days -- so an END-OF-FILE on a short fast doesn't seem unreasonable to me.

[Nikodemus Siivola (nikodemus)]

commit ac93aa515b197d751dad85d70432ebc87fac420a
Author: Nikodemus Siivola <email address hidden>
Date: Tue Apr 24 09:16:47 2012 +0300

    better reader-errors for COMPILE-FILE

     * Make SIMPLE-READER-PACKAGE-ERROR a subclass of PACKAGE-ERROR.

     * Make reader signal a SIMPLE-READER-PACKAGE-ERROR for missing packages,
       instead of a vanilla PACKAGE-ERROR: that way get the position reported as
       well.

     * Factor out line and column reporting logic for reader-errors into a
       separate function, and allow using other than current file position.

     * READ-FOR-COMPILE-FILE needs to use COMPILER-ERROR, and
       INPUT-ERROR-IN-COMPILE-FILE is a subclass of READER-ERROR, not a
       FATAL-COMPILER-CONDITION.

     * *COMPILER-ERROR-BAILOUT* binding in SUB-COMPILE-FILE was missing the
       condition argument from the lambda-list, and should not mumble to
       *STANDARD-OUTPUT*.

     This patch converts all input errors into COMPILE-FILE failures without
     dropping into the debugger. That might be taking things too far, though --
     but the question of "which errors should we let enter the debugger" has no
     obvious answers to me at least. Perhaps *COMPILER-HANDLED-ERRORS* is the way
     to go?

     Fixes lp#493380