fix(rome_formatter): Printer fill fits

[MichaReiser]

Summary

This fixes the issue why the test is currently failing in #3251

The specific snipped triggering the issue is:

  <div>
    ENddddDSIIIN <div>
      texttexttexttexttexttexttexttexttexttexttexttextextffg
    </div>{" "}
    HRS
  </div>

That generates the following IR

[
  group(["<div>"]),
  indent([
    hard_line_break,
    fill([
        ["ENddddDSIIIN"],
        [
          if_group_breaks(["{" "}", soft_line_break]),
          if_group_fits_on_line([" "])
        ],
        [
          best_fitting([
            [
              [
                group(["<div>"]),
                "texttexttexttexttexttexttexttexttexttexttexttextextffg",
                "</div>"
              ]
            ]
            [
              [
                group(["<div>"]),
                indent([
                  hard_line_break,
                  fill([
                      ["texttexttexttexttexttexttexttexttexttexttexttextextffg"]
                  ])
                ]),
                hard_line_break,
                "</div>"
              ]
            ]
          ])
        ],
        [
          if_group_breaks(["{" "}", soft_line_break]),
          if_group_fits_on_line([" "])
        ],
        ["HRS"]
      ]
    ])
  ]),
  hard_line_break,
  "</div>;",
  hard_line_break
]

The issue is the combination of fill with best_fitting.

• Fill tests if ENddddDSIIIN fits on the line -> yes. Print the entry
• Fill tests if the space and the <div>text...</div> fits on the line -> yes. Print the entry
• The best fitting now tests if its content up to the first hard line break fits on the line. This is includes the following content: <div>text...</div> HRS. Notice how it includes the HRS which is from the next fill entry.

The measuring if the best fitting should stop at the next separator because fill will make that separator expand if it otherwise risks exceeding the line width. Now, stopping at the next separator isn't trivial. However, there's no need for best_fitting to even test if it fits because fill already tested that.

That's why the fix is somewhat simple. All that is necessary is to set that we know it will fit and that the printer can simply use the first variant.

But what about...

if the fill element doesn't fit. Do we not have the same problem then? Not really, because the element gets printed in expanded mode and this also applies for the separator coming right after. Since the separator must contain a soft line break the printer either decides that the content fits (for best fitting) or expands (group).

Test Plan

Tested that #3251 now formats correctly

[netlify]

✅ Deploy Preview for rometools canceled.

Name	Link
🔨 Latest commit	f2e3a09
🔍 Latest deploy log	https://app.netlify.com/sites/rometools/deploys/63371cd3296d07000b87620f

[MichaReiser]

These two changes aren't related to the bug but align our IR with Prettiers and made it easier to debug the issue

[MichaReiser]

@denbezrukov this should fix the failing test in #3251 . @ematipico please go ahead with merging this PR and then #3251 on Monday (I'll check in on Saturday and merge the changes myself if they are approved but otherwise have to delegate, I'm sorry)

[github-actions]

Playground for commit 91b0eb2

[MichaReiser]

!bench_formatter

[github-actions]

Formatter Benchmark Results

group                                    main                                   pr
-----                                    ----                                   --
formatter/checker.ts                     1.00    388.7±2.36ms     6.7 MB/sec    1.01    393.3±3.11ms     6.6 MB/sec
formatter/compiler.js                    1.00    217.2±1.26ms     4.8 MB/sec    1.01    219.5±1.26ms     4.8 MB/sec
formatter/d3.min.js                      1.00    172.1±0.69ms  1559.6 KB/sec    1.00    172.9±0.72ms  1552.7 KB/sec
formatter/dojo.js                        1.00     11.6±0.10ms     5.9 MB/sec    1.01     11.8±0.06ms     5.8 MB/sec
formatter/ios.d.ts                       1.00    248.6±1.82ms     7.5 MB/sec    1.00    249.0±1.12ms     7.5 MB/sec
formatter/jquery.min.js                  1.00     47.6±0.49ms  1777.7 KB/sec    1.00     47.7±0.26ms  1775.3 KB/sec
formatter/math.js                        1.00    335.5±2.45ms  1976.6 KB/sec    1.00    337.1±2.03ms  1966.9 KB/sec
formatter/parser.ts                      1.00      8.1±0.03ms     6.1 MB/sec    1.01      8.1±0.04ms     6.0 MB/sec
formatter/pixi.min.js                    1.00    187.9±0.90ms     2.3 MB/sec    1.01    190.4±0.88ms     2.3 MB/sec
formatter/react-dom.production.min.js    1.00     57.8±0.61ms  2040.3 KB/sec    1.00     58.0±0.63ms  2031.8 KB/sec
formatter/react.production.min.js        1.00      2.8±0.02ms     2.2 MB/sec    1.01      2.8±0.02ms     2.2 MB/sec
formatter/router.ts                      1.00      6.6±0.11ms     9.4 MB/sec    1.01      6.6±0.05ms     9.3 MB/sec
formatter/tex-chtml-full.js              1.00    436.2±1.94ms     2.1 MB/sec    1.00    438.1±1.39ms     2.1 MB/sec
formatter/three.min.js                   1.00    223.7±0.96ms     2.6 MB/sec    1.01    224.8±1.04ms     2.6 MB/sec
formatter/typescript.js                  1.00   1430.9±6.30ms     6.6 MB/sec    1.01   1440.7±5.87ms     6.6 MB/sec
formatter/vue.global.prod.js             1.00     73.7±0.48ms  1673.9 KB/sec    1.01     74.6±0.95ms  1653.9 KB/sec