Add failing test for partials which contain contextual components

[GavinJoyce]

related to #15621

TODO:

• bump @glimmer dependencies to ^0.25.4 and verify new tests pass
• address unrelated regression outlined here : Add failing test for partials which contain contextual components #15777 (comment)

[GavinJoyce]

it looks like updating to glimmer-vm 0.25.4 results in three test failures:

[GavinJoyce]

Here's the glimmer-vm diff: glimmerjs/glimmer-vm@v0.25.3...v0.25.4

[GavinJoyce]

@rwjblue here's what I believe to be the current state of play:

• A regression was introduced in Ember 2.15 time frame (test here) and is fixed in glimmer-vm 0.25.4
• glimmer-vm 0.25.4 introduces a regression which results in this test failing, it passes with glimmer-vm 0.25.3.
• Your additional tests in Failing tests for {{partial issues in 2.15. #15674 aren't fixed with glimmer-vm 0.25.4. I'm yet unclear if these are regressions introduced with 2.15, or if they have been there for longer

[GavinJoyce]

Digging into the failing test a little:

in glimmer-vm 0.25.3, the get opcode results in an InternalReferenceHelper of classHelper (which is correct):

in glimmer-vm 0.25.4, the maybeLocal opcode results in a RootPropertyReference with a value of true (which is incorrect):

[GavinJoyce]

Aha, wrapComponentClassAttribute currently only supports Ops.Get, not Ops.MaybeLocal:

ember.js/packages/ember-glimmer/lib/utils/bindings.ts

Lines 50 to 54 in ef18807

	if (type === Ops.Get) {
	let getExp = values[index];
	let path = getExp[2];
	let propName = path[path.length - 1];
	hash[1][index] = [Ops.Helper, ['-class'], [getExp, propName]];

Interesting comment, I wonder if this will help simplify things:

ember.js/packages/ember-glimmer/lib/utils/bindings.ts

Line 38 in ef18807

// TODO we should probably do this transform at build time

[GavinJoyce]

@rwjblue 🍏 and ready for review

[rwjblue]

Thank you very much for working on this!!

[tomdale]

Impressive work, @GavinJoyce. I agree with the comment: ideally this fixing up should happen at the AST level, not the opcode level. I'm afraid that future plans for generating more optimized bytecode will probably continue to cause breakage here if it's relying on specific opcodes instead of higher-level semantics.