Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jinja2 2.9 introduces change with free variables in loops that breaks Lektor #649

Closed
freakboy3742 opened this issue Jan 9, 2017 · 3 comments

Comments

@freakboy3742
Copy link

commented Jan 9, 2017

Using Lektor 2.3; If you have a project with a sitemap (using the template suggested by the Lektor docs):

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  {%- for page in [site.root] if page != this recursive %}
  <url><loc>{{ page|url(external=true) }}</loc></url>
  {{- loop(page.children) }}
  {%- endfor %}
</urlset>

and you have jinja2 2.9 - 2.9.3, in your environment, you get a build error:

(lektor) hammer:pybee.org rkm$ lektor build
Started build
U ar_AR/sitemap.xml
E ar_AR/sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)
U sitemap.xml
E sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)
U pt_BR/sitemap.xml
E pt_BR/sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)
U zh_TW/sitemap.xml
E zh_TW/sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)

Downgrading to Jinja2 2.8.1 seems to resolve the problem.

Reporting there because it would seem to be a regression in Jinja2; however, it's also been reported as lektor/lektor#343 in case it's a usage error.

@mitsuhiko

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

Indeed this is a scoping bug that regressed.

Note to self: this is caused by the filter expression being scoped to the same scope. This needs to be changed to be an independent scope.

@mitsuhiko

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

Second note to self: the old and new compilation for loop filters is unsound. It compiles to two different modes depending on the extended loop flag but which on the generated code side produces different scoping rules. In extended loops a new frame is needed according to the generated code, in non extended looping the scope can be reused.

However if the latter compilation mode is actually valid is unclear and needs to be investigated.

@mitsuhiko mitsuhiko closed this in ef71801 Jan 9, 2017

@mitsuhiko

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

At least fixing those bugs is easy now but man those regressions suck. Needs better test coverage :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.