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#

basis/compiler/tests/peg-regression.factor

@@ -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

basis/compiler/tree/propagation/inlining/inlining.factor

@@ -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 ] }