Allow interpolated string adjacent to '=' (e.g. C(Name=$"value"))

[edgarfgp]

Fixes #16696.

Problem

When an interpolated string immediately follows = with no space, the lexer greedily matches =$ as a single INFIX_COMPARE_OP token (since $ is an operator character). checkExprOp then rejects it with FS0035 ('$' is not permitted as a character in operator names), so property/named-argument initialization with an interpolated string fails to parse.

Before

type C() =
    member val Name = "" with get, set

let a = C(Name="123")     // works
let b = C(Name=$"123")    // error FS0035: '$' is not permitted as a character in operator names
let c = C(Name= $"123")   // works (space before $)

let x =$"123"             // error FS0035
let y =$"hello {world}"   // error FS0035

After

let b = C(Name=$"123")            // works → "123"
let x =$"hello {world}"           // works → "hello world"
let y =$"%d{n}"                   // works → typed hole
let z = { Name=$"value" }         // works in record creation
let w = { r with Name=$"value" }  // works in record copy
let t =$"""triple {x}"""          // works for triple-quoted

The produced AST is identical to the spaced form = $"...", so all downstream tooling sees the same tree.

Solution

A lexer-level rule for the exact 3-character sequence =$":

| '=' '$' '"' {
      lexbuf.LexemeLength <- 1
      lexbuf.EndPos <- lexbuf.StartPos.ShiftColumnBy(1)
      EQUALS }

It matches =$" (winning over the 2-char operator rule via longest-match), emits EQUALS, then rewinds LexemeLength to 1 so the next scan begins at $". The existing interpolated-string lexer then processes the rest — including interpolation holes and triple-quoted forms. Because the fix is in the lexer, it applies in every position where = $"..." is valid (let-bindings, named args, record creation/copy), not just one grammar rule.

The previously-internal LexBuffer.LexemeLength setter is exposed in prim-lexing.fsi (no change to the public API surface — the type is internal).

Scope

Limited to the $" opening sequence (single- and triple-quoted). Defining or using =$ as a custom operator remains rejected (FS0035), preserving the "reserved for future use" semantics.

Open question — should we also handle the remaining variants?

These forms still require a space and continue to error as before (regression tests assert this):

let x =$@"abc"        // verbatim interpolated   ($@)
let y =@$"abc"        // verbatim interpolated   (@$)
let z =$$"""abc"""    // extended interpolated   ($$)

They're out of scope for the reported issue (which only shows the $" form), and the workaround is a single space. They could be added with the same lexer technique (longer =$@", =@$", =$$""" rules with a larger rewind), at the cost of more lexer rules. Do we want to cover them in this PR, defer to a follow-up, or leave them as-is?

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Warning

No PR link found in some release notes, please consider adding it.

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No current pull request URL (#19820) found, please consider adding it

[T-Gro]

Clean, minimal fix at exactly the right layer. The approach is sound:

Correctness

• The 3-char rule '=' '$' '"' wins by longest-match over the 2-char =$ that the INFIX_COMPARE_OP rule would match (since " is not in op_char). This is the key insight that makes the fix safe.
• The rewind via LexemeLength <- 1 + EndPos adjustment correctly lets the regular interpolated-string lexer take over at $", including triple-quoted forms ($"""...""" — first three chars =$" still trigger the rule, then next scan sees $""" and the existing triple-quote handling kicks in).
• Negative cases (=, defining (=$), infix =$) all still route through checkExprOp and reject correctly.

API surface

• LexemeLength setter is exposed in prim-lexing.fsi but LexBuffer<'Char> is ype internal — no public API impact.

CI: All 50 check runs green.

Tests: Excellent coverage — positive cases (let-bindings, named args, records, record-copy, holes, typed holes), negative cases (non-quote, operator definition, infix usage, verbatim out-of-scope), syntax-tree baselines, and the space-separated form unchanged.

One minor suggestion (non-blocking): consider adding a component test that compiles and runs =$"""triple {x}""" alongside the syntax-tree baseline. The baseline proves parsing but not codegen/execution for that form.

Nice work!

[auduchinok]

This change feels very ad-hoc. It workarounds a specific case that has an explicit existing limitation in the language. The case arises due to non-idiomatic formatting of the code, i.e. due to the missing spaces around =.

@edgarfgp Since this PR changes what is allowed by the language, have you considered changing the rule that causes the problem in the first place instead of trying to workaround it?

The workaround is done by exposing more lexer internals and doing processing after a token is lexed. Modifying tokens like this is sometimes done in the compiler already, but for operators it's done in LexFilter. Why this approach is better than the existing one?

The tests look as if they are completely AI-generated: there's a lot of noise that hides the relevant parts of the code, and the tests effectively duplicate each other, since they only test simple adjacent = and $, while not testing how different kinds of interpolations interoperate, how operators are lexed differently now due to this change. I think we should not merge changes with such tests.

[auduchinok]

@edgarfgp Could you minimize the test, so it's clear what it tests?

[auduchinok]

@edgarfgp What other implications may this change bring? Have you considered following approach used for operators and type arguments?