Fix import assertion occurrences crash

[weswigham]

This also makes import assertion parsing more generous, parsing any expression for an import assertion value, and then only later issuing an error on non-string-literal expressions.

[DanielRosenwasser]

What's this guarding on? Unterminated string at EOF?

[weswigham]

Response here

But generally, sort of, yeah - short ill-formed strings without quotes.

[DanielRosenwasser]

Do you have the old stack-trace so we can track any possible duplicates?

[weswigham]

I changed this to parseAssignmentExpressionOrHigher since it's what objects parse out for values, so covers the most likely set of expressions people may mistakenly put here (which is to say: any expression except comma expressions). There are other common "mistakes" that people may make for import assertions - passing an arbitrary expression instead of an object-like-thing, using computed property names or shorthand or rest properties... But handling those gracefully would require more involved alterations to how we parse import assertions.

[weswigham]

This line alone is technically the minimal fix to stop the crash, but it doesn't really get at the root cause (forcibly parsing a non-string-thing as a string) and instead treats the symptom (stopping adjusting the span bounds for strings shorter than a minimum quoted string length). I'm of a mind to keep this, since I'm pretty sure getTextSpan crashes on empty string literals without it, too (because createTextSpan demands a nonzero nonnegative span length), though I don't know of a repro for that case.

[weswigham]

Do you have the old stack-trace so we can track any possible duplicates?

Something like

Error: length < 0
      at createTextSpan (src\compiler\utilitiesPublic.ts:98:19)
      at Object.createTextSpanFromBounds (src\compiler\utilitiesPublic.ts:105:16)
      at getTextSpan (src\services\findAllReferences.ts:534:16)
      at entryToDocumentSpan (src\services\findAllReferences.ts:411:30)
      at toHighlightSpan (src\services\findAllReferences.ts:505:30)
      at Array.map (<anonymous>)
      at getSemanticDocumentHighlights (src\services\documentHighlights.ts:34:58)
      at Object.getDocumentHighlights (src\services\documentHighlights.ts:19:20) 
      at getDocumentHighlights (src\services\services.ts:1761:39)
      at Object.getOccurrencesAtPosition (src\services\services.ts:1743:17)      

however this may not fix all instances of that assertion being triggered, as it's a generic assertion failure crash for any zero-or-less-length text spans; so any time span math happens on ill-formed nodes, this stack trace is liable to appear. I'm hoping, as I said here that this should defensively remove the assertion crash in most cases by eliminating the string literal span math when it's obviously wrong, however odd span length may still filter in via other means (eg, from bad initial node positions and lengths).