Are we covering cases like {{ 'foo'|nosuchfilter if false else 'bar' }} and {{ 'foo' if true else 'bar'|nosuchfilter }} - neither should raise (since the filter is not actually used, but based on the code it looks like it may raise..

Are we covering cases like {{ 'foo'|nosuchfilter if false else 'bar' }} and {{ 'foo' if true else 'bar'|nosuchfilter }} - neither should raise (since the filter is not actually used, but based on the code it looks like it may raise..

Right, I forgot to account for those but probably should (and will) too.

I have the feeling any block-level check is likely to have problematic edge cases - can't we just let it fail when actually accessing the filter?

I have the feeling any block-level check is likely to have problematic edge cases - can't we just let it fail when actually accessing the filter?

Hmm that's true. The error won't be as helpful though: TypeError: 'NoneType' object is not callable

Good point, that error is awful and filters that are sometimes but not always undefined are very much an edge case for which we probably shouldn't sacrifice error verboseness with other, more common, cases

Could we compile filters to something like this at the beginning of the template?

try:
    filter_tmp_0 = self.filters['filter_name']
except KeyError:
    @internalcode
    def filter_tmp_0(*unused):
        raise TemplateRuntimeError("no filter named 'filter_name'")

Then the code where the filter is actually used just uses filter_tmp_0 which will either call the filter or raise an exception - without adding extra runtime overhead every time the filter is actually invoked.

Ooh that's a good idea! I moved it to pull_dependencies in the new commit. Let me know if I misunderstood. Will address conditional expressions next.

I'm working on a separate PR to create an if 'name' is filter test.