[pypy-dev] Blocked Block error

[Armin Rigo]

Hi Ryan,

On 21 April 2014 20:37, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> What I want to know is the meaning of the Blocked Block error. I always get
> that error at least once. Usually I can solve it myself, but I'm curious as
> to what it actually means.

When RPython does type inference, it works incrementally.  There are
often some operations that don't seem to make sense temporarily, but
this problem will be resolved by the type inference done on other
parts of the same program.  The typical example is "x = foo.attr"
where, as far as we know, the instance "foo" has no attribute "attr".
This looks like an error, but often isn't: if we continue somewhere
else, we'll see "foo.attr = 42" and then know that "foo" really has an
"attr".

"Blocked Blocks" errors are raised if at the end of the type inference
process there are still such unresolved positions left.

If several errors are printed, often only one of them is relevant
(e.g. a real typo).

The error can also occur becuse the particular type inference done can
prove that "foo" is always None in this case, so that reading
"foo.attr" doesn't make sense.  That can be annoying when running
tests that only try to translate a part of the program.  It's usually
easy to find a workaround, e.g. by inserting "assert foo is not None".
 Unlike "x = foo.attr", which blocks, an assert that always fails does
not create a blocked block, but will simply always raise
AssertionError in the translated program.  (The distinction is a bit
artificial.  We could also never create blocked blocks and simply
raise AssertionErrors if this point is executed, but that seems like a
bad idea in general...)


A bientôt,

Armin.