Currently, the Jinja2 context objects, such as method_context, overloads_context, et al. are used both as the Jinja2 template context objects and as means of passing information/context during bindings generation.

For example, method_context holds on an IdlType (which is not used by Jinja2).

This conflation of responsibilities leads to code that's difficult to maintain.

For example, there's currently an obvious bug in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/scripts/v8_interface.py?rcl=0f799230c0f27e3e8882868f46d9d5cefe9c8c6d&l=774, since overloads_context is called both for methods (that do have a name) and constructors (that don't), but I wasn't able to easily reason out a fix.

Another code smell is just above on line 772, where we are using any() to determine whether methods have origin trial features. This is typically an indication that this information was available at one time, but then was lost and has to be reconstructed. In an ideal world, some context/builder object would hold on to this data and it would need to be grafter onto or extracted by inspection out of the Jinja2 context object.

However, there's a definite cost to this new ideal world. I gave it a shot this week, and realized it's a fairly large project that probably needs more than a 5% contributor investment.

At the same time, I am optimistic. Now that we have unit tests, we can actually start making these changes safely.