Fix unintended lstrip_blocks behavior#1183
Conversation
|
Today I got back to this for a bit and realized that the way I was testing it on my 100k sample templates was wrong, I didn't actually enable lstrip_blocks in my environment. So I repeated the test and the result is great. The generated parse trees after #857 were actually different in many cases from the parse trees generated before #857, and the parse trees after #1183 were in all cases the same as the ones before #857. I made the same mistake when comparing the parse trees when implementing #857 so this shows how the change of behavior went unnoticed and it also confirms that this fix returns to the correct behavior while keeping the much better performance. |
|
Awesome work, thanks for following up. I've actually got this checked out right now, rebasing to 2.11.x and adding a changelog. Should be released later today. |
|
I'm not sure how it happened, but you opened a PR from a different user (xponea), so I can't force push to the branch. If there's an option to allow pushes on the PR, please enable it. Otherwise, can you do the following: Changelog entry: |
|
@petee-d ping on getting this rebased |
Introduced in pallets#858. Tests will follow, also results of performance testing.
Also did peformance tests for the previous fix and saw no measurable impact.
dc6445b to
7163513
Compare
|
@davidism Sorry for the delay, I was mostly offline the past few days. Pushed the rebase and change log entry to my fork branch. I don't see the option to let you make edits to this PR created from a fork, as described in https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork. If you need to do more edits, feel free to copy the branch from my fork and recreate the PR. |
|
Looks good, thanks! |

Introduced in #858. Closes #1138