Open appleby opened 5 years ago
I managed to tickle this bug again, this time while running make test-tweedledum
.
Seems to consistently happen in TEST-COMPILER-HOOK
, but this time when testing commuting-blocks.quil
(last time in parametric-gates.quil
).
Immediately re-ran the test to see if it would reproduce, but no luck. On the second run, the tests completed successfully.
TEST-COMPILER-HOOK
Unhandled SB-PCL::NO-APPLICABLE-METHOD-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
{10005004F3}>:
There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION CL-QUIL:APPLICATION-PARAMETERS (1)>
when called with arguments
(NIL).
See also:
The ANSI Standard, Section 7.6.6
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10005004F3}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1002DA9553}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1002DA9553}>)
2: (INVOKE-DEBUGGER #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1002DA9553}>)
3: (ERROR SB-PCL::NO-APPLICABLE-METHOD-ERROR :GENERIC-FUNCTION #<STANDARD-GENERIC-FUNCTION CL-QUIL:APPLICATION-PARAMETERS (1)> :ARGS (NIL))
4: ((:METHOD NO-APPLICABLE-METHOD (T)) #<STANDARD-GENERIC-FUNCTION CL-QUIL:APPLICATION-PARAMETERS (1)> NIL) [fast-method]
5: (SB-PCL::CALL-NO-APPLICABLE-METHOD #<STANDARD-GENERIC-FUNCTION CL-QUIL:APPLICATION-PARAMETERS (1)> (NIL))
6: ((LABELS CL-QUIL::INSTRUCTION-TYPE :IN CL-QUIL::COMPRESS-INSTRUCTIONS-WITH-POSSIBLY-UNKNOWN-PARAMS) NIL)
7: ((LABELS CL-QUIL::GRAB-FIRST-TWO-BLOCKS :IN CL-QUIL::COMPRESS-INSTRUCTIONS-WITH-POSSIBLY-UNKNOWN-PARAMS) NIL)
8: (CL-QUIL::COMPRESS-INSTRUCTIONS-WITH-POSSIBLY-UNKNOWN-PARAMS (#<RX(pi/2) 1> #<RZ(pi/2) 1> #<PISWAP(pi) 0 1> #<RZ(-pi/2) 0> #<RX(pi/2) 0> #<PISWAP(pi) 0 1> #<RZ(pi/2) 0> #<RX(pi/2) 1>) #<CL-QUIL::CHIP-SPECIFICATION of 5:4 objects> #S(CL-QUIL::COMPRESSOR-CONTEXT :AQVM #S(CL-QUIL::ANTISOCIAL-QVM :WFS #(#(#C(1.0d0 0.0d0) #C(0.0d0 0.0d0)) #(#C(1.0d0 0.0d0) #C(0.0d0 0.0d0)) #(#C(1.0d0 0.0d0) #C(0.0d0 0.0d0)) #(#C(1.0d0 0.0d0) #C(0.0d0 0.0d0)) #(#C(1.0d0 0.0d0) #C(0.0d0 0.0d0))) :INTERNAL-INDICES #(0 0 0 0 0)) :CHIP-SPECIFICATION #<CL-QUIL::CHIP-SPECIFICATION of 5:4 objects>) NIL)
9: ((LABELS CL-QUIL::TRANSITION-GOVERNOR-STATE :IN CL-QUIL::COMPRESS-INSTRUCTIONS) 1 0 :FLUSHING NIL)
10: ((LABELS CL-QUIL::TRANSITION-GOVERNOR-STATE :IN CL-QUIL::COMPRESS-INSTRUCTIONS) 1 1 :QUEUEING NIL)
11: ((LABELS CL-QUIL::PROCESS-INSTRUCTION :IN CL-QUIL::COMPRESS-INSTRUCTIONS) #<PISWAP(pi) 1 2> 1 1)
12: ((LABELS CL-QUIL::TRANSITION-GOVERNOR-STATE :IN CL-QUIL::COMPRESS-INSTRUCTIONS) :GLOBAL :GLOBAL :FLUSHING NIL)
13: (CL-QUIL::COMPRESS-INSTRUCTIONS (#<RZ(pi/4) 2> #<RZ(pi) 1> #<RZ(0.32175055439664235) 0> #<RX(pi/2) 2> #<RX(pi/2) 1> #<RX(pi/2) 0> #<RZ(pi) 2> #<RZ(pi/2) 1> #<RZ(0.0) 0> #<RX(-pi/2) 2> #<RX(-pi/2) 1> #<RX(-pi/2) 0> ...) #<CL-QUIL::CHIP-SPECIFICATION of 5:4 objects> :PROTOQUIL T)
14: ((LABELS CL-QUIL::PROCESS-BLOCK :IN COMPILER-HOOK) #<CL-QUIL::BASIC-BLOCK ENTRY-BLK-3600 len:17 in:0 out:term {100234B1D3}> NIL)
15: (COMPILER-HOOK #<PARSED-PROGRAM {100233F413}> #<CL-QUIL::CHIP-SPECIFICATION of 5:4 objects> :PROTOQUIL NIL :REWIRING-TYPE NIL)
16: (COMPARE-COMPILED #P"/Users/mappleby/src/repos/rigetti/quilc/tests/compiler-hook-test-files/commuting-blocks.quil" :PISWAP)
17: ((LABELS TEST-COMPILER-HOOK :IN TEST-COMPILER-HOOK))
18: ((LABELS FIASCO::RUN-TEST-BODY :IN FIASCO::RUN-TEST-BODY-IN-HANDLERS))
19: (FIASCO::CALL-WITH-TEST-HANDLERS #<CLOSURE (LAMBDA NIL :IN FIASCO::RUN-TEST-BODY-IN-HANDLERS) {1003BA8CEB}>)
20: (FIASCO::PRETTY-RUN-TEST #<test TEST-COMPILER-HOOK> #<FUNCTION (LABELS TEST-COMPILER-HOOK :IN TEST-COMPILER-HOOK) {23B07D3B}>)
21: ((LABELS #:BODY-SYM0 :IN TEST-COMPILER-HOOK))
22: (TEST-COMPILER-HOOK)
Accept the mystery.
Maybe we need the equivalent of pytest-rerunfailures, but for fiasco. Then I wouldn't even have to think about it :-D
That backtrace ought to be enough to reproduce the bug. Let's see!
I should have mentioned that that last backtrace came from a local branch with my gate-modifiers reversal changes applied. I assumed it was unrelated because the error is so similar to the others above, but you never know.
It isn't enough. For whoever it happens to next: save the contents of the arguments to CL-QUIL::COMPRESS-INSTRUCTIONS-WITH-POSSIBLY-UNKNOWN-PARAMS
, frame 8 in the above.
I observed this today when running tests, but could not reproduce. It popped up in TEST-COMPILER-HOOK
on the commuting-blocks
examples under state prep compression.
The following error occurred for me while running the quilc test suite several weeks ago, but I have not been able to reproduce since. It recently came up in a slack discussion thread @ecpeterson also ran into this error while attempting to run the
make test-tweedledum
target.Reproduction steps are unknown.
Here is the failure from ecpeterson's run, copy/pasted from slack: