Fix regression. If a parsing word called the compiler, it might compile a caller of a generic before the generic gets built, which would throw an error since the inferred effect of the generic might have less inputs than the combination's dispatch#

db4
Slava Pestov 2008-11-03 20:59:48 -06:00
parent dc85ed3d56
commit 06b99c31ee
2 changed files with 35 additions and 0 deletions
basis/compiler
tree/propagation/inlining

View File

@ -0,0 +1,26 @@
! Calling the compiler at parse time and having it compile
! generic words defined in the current compilation unit would
! fail. This is a regression from the 'remake-generic'
! optimization, which would batch generic word updates at the
! end of a compilation unit.
USING: kernel accessors peg.ebnf ;
IN: compiler.tests
TUPLE: pipeline-expr background ;
GENERIC: blah ( a -- b )
M: pipeline-expr blah ;
: ast>pipeline-expr ( -- obj )
pipeline-expr new blah ;
EBNF: expr
pipeline = "hello" => [[ ast>pipeline-expr ]]
;EBNF
USE: tools.test
[ t ] [ \ expr compiled>> ] unit-test
[ t ] [ \ ast>pipeline-expr compiled>> ] unit-test

View File

@ -164,7 +164,16 @@ SYMBOL: history
first object swap eliminate-dispatch ;
: do-inlining ( #call word -- ? )
#! If the generic was defined in an outer compilation unit,
#! then it doesn't have a definition yet; the definition
#! is built at the end of the compilation unit. We do not
#! attempt inlining at this stage since the stack discipline
#! is not finalized yet, so dispatch# might return an out
#! of bounds value. This case comes up if a parsing word
#! calls the compiler at parse time (doing so is
#! discouraged, but it should still work.)
{
{ [ dup deferred? ] [ 2drop f ] }
{ [ dup custom-inlining? ] [ inline-custom ] }
{ [ dup always-inline-word? ] [ inline-word ] }
{ [ dup standard-generic? ] [ inline-standard-method ] }