if loading an .asd errors then the broken system gets registered

Bug #1515372 reported by Attila Lendvai on 2015-11-11
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ASDF
Medium
Faré

Bug Description

essentially:

CL-USER> (asdf:defsystem :foo :defsystem-depends-on (:nonexistent) :components ((:file "testfile")))
; Evaluation aborted on Component :NONEXISTENT not found, required by NIL.
CL-USER> (asdf:find-system :foo) <---- this should not find the system
#<ASDF/SYSTEM:SYSTEM "foo">
CL-USER> (asdf:component-children (asdf:find-system :foo))
NIL

the real-world scenario is:

CL-USER> (ql:quickload :projectured.sdl.test) <--- this fails due to the :defsystem-depends-on (:hu.dwim.asdf)
While evaluating the form starting at line 7, column 0
  of #P"/home/alendvai/common-lisp/projectured/projectured.sdl.test.asd":; Evaluation aborted on #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {1004193073}>.
CL-USER> (ql:quickload :projectured.sdl.test)
To load "projectured.sdl.test":
  Load 1 ASDF system:
    projectured.sdl.test
; Loading "projectured.sdl.test"

(:PROJECTURED.SDL.TEST) <---- looks like everything is fine because the system is empty
CL-USER>

Faré (fahree) wrote :

See also duplicate bug #1532584 where the same pathological behavior is reached by using an invalid component type while parsing the system.

The way defsystem is parsed should be revised.

Solution 1: have an unwind-protect unregister the system if the evaluation failed.

Solution 2: have a flag in the system that indicates whether it's been successfully parsed; if not, report error, or reparse, or ouch. [Sounds more complex, for less results]

Solution 3: rewrite the entire parsing infrastructure inherited from ASDF 1, with something better that works bottom up rather than top down (though it will have to maintain a top-down context; so I suppose that really means, distinguishing build-time component context objects from finished component objects; meh).

Faré (fahree) wrote :

See also duplicate bug #1581204

Faré (fahree) wrote :

Regarding solution 1, unregistering may or may not be good, but it also may not be enough: other objects might already have linked to that system using find-system, and the system object probably shouldn't be left in a state that silently fails to fail when used even though it's actually bogus. A change-class to a system that fails to perform compile-op, etc., might be appropriate.

So, maybe both solution 1 *and* 2.

Faré (fahree) wrote :
Changed in asdf:
assignee: nobody → Faré (fahree)
importance: Undecided → Low
status: New → In Progress
Faré (fahree) wrote :

This is fixed in the "plan" branch, MR !37, to be merged as part of ASDF 3.3.

Changed in asdf:
importance: Low → Medium
milestone: none → 3.3
status: In Progress → Fix Committed
Changed in asdf:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers