ember.js: [Bug] Ember's template compiler on 3.25 complains about ~ in a comment

Running ember serve with ember-source 3.25 leads to:

unexpectedly found "!~" when slicing source, but expected ""
unexpectedly found " comment ~" when slicing source, but expected " comment "

These correspond to these two lines of HBS (they are in different files, I’ve just put them here for conciseness):

{{~!~}}
{{! comment ~}}

This didn’t happen before. Not sure if this is a bug in the template compiler or what I did before was not supposed to work.

Funny thing is that these “errors” appear only sometimes. I can’t seem to understand when they appear and when they don’t.

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 10
  • Comments: 36 (25 by maintainers)

Commits related to this issue

Most upvoted comments

We’re waiting on some glimmer vm refactoring work atm, at which point, vm fixes very likely won’t be back portable, depending on complexity of the change. We’ll see what happens once the long overdue maintenance is done. (The linked fix above looks fairly isolated and straight forward tho)

Stay tuned!

FWIW we’re seeing similar issues:

unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<form" when slicing source, but expected "class"
unexpectedly found "<form" when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<asid" when slicing source, but expected "class"
unexpectedly found "<asid" when slicing source, but expected "class"
unexpectedly found "<asid" when slicing source, but expected "class"
unexpectedly found "<asid" when slicing source, but expected "class"
unexpectedly found "<asid" when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"
unexpectedly found "<div " when slicing source, but expected "class"

interestingly we are only seeing it with class and I’m wondering if it is related to us using ember-css-modules.

Someone probably needs to do the work in @glimmer/syntax

This is also impacting consumers of the ember-basic-dropdown addon (which uses ember-maybe-in-element which creates synthetic attributes). I don’t really see how to work around this in that addon as ember-css-modules was able to.

I would argue this is well worth fixing (at a minimum: don’t output the warning if the node is synthetic, if possible). To developers, this looks like there is a syntax error somewhere. Any warnings that appear during the course of migration are particularly distracting, because we are on the lookout for new problems.

One could require plugins to set the attribute’s loc.source:

newAttr.loc = {
  source: '(synthetic)',
  start: { line: 1, column: 0 },
  end: { line: 1, column: 0 }
};

and key off that . . . ?

its a bug in the sense that it outputs a meaningless warning, its not actually an issue beyond that

I poked at this a bit today, and it looks like adding any synthetic AttrNode in a template transform will trigger this.

I don’t have great in-depth knowledge of the AST normalization process, but these lines seem like they’re treating the loc of the synthetic node as a real location that they can read from in source, which is triggering the warning here.

I hit this in a repo that uses ember-css-modules the same way @Turbo87 described. It definitely seems plausible it’s related to the template transform happening in that package, or from the other comments here from template transforms in general

@boris-petrov ok, that gives me some motivation to upgrade.

@nelstrom - I am on the latest - 3.27.5. Not sure if that was what resolved the issue though. But the fact is that I haven’t seen these warnings in a while now.