🐛 Panic `byte index 1 is not a char boundary` in `display/frame.rs`

[qarmin]

Environment information

CLI:
  Version:                      0.0.0 (self compiled 6b183872744780ac55f7e6f45ac14f60b2796d49)
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           linux

Environment:
  BIOME_LOG_PATH:               unset
  BIOME_LOG_PREFIX_NAME:        unset
  BIOME_CONFIG_PATH:            unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           unset
  JS_RUNTIME_NAME:              unset
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       unset

Workspace:
  Open Documents:               0

What happened?

File content(at the bottom should be attached raw, not formatted file - github removes some non-printable characters, so copying from here may not work):

。<script>
{</script>

command

timeout -v 150 biome lint TEST___FILE.vue

cause this

/opt/BROKEN_FILES_DIR/newmessage_IDX_0_RAND_327260588916434309433686_minimized_824.vue:2:2 parse ━━━━━━━━━━

  × expected `}` but instead the file ends
  
    1 │ 。<script>
  > 2 │ {</script>
      │  
  
  i the file ends here
  
  > 1 │ 。<script>
      │ Biome encountered an unexpected error

This is a bug in Biome, not an error in your code, and we would appreciate it if you could report it to https://github.com/biomejs/biome/issues/ along with the following information to help us fixing the issue:

Source Location: crates/biome_diagnostics/src/display/frame.rs:229:35
Thread Name: main
Message: byte index 1 is not a char boundary; it is inside '。' (bytes 0..3) of `。<script>`


##### Automatic Fuzzer note, output status "None", output signal "Some(6)"

compressed.zip

Expected result

No crash

Code of Conduct

• I agree to follow Biome's Code of Conduct

[arendjr]

This seems to be caused by the hacks we do for partial Vue/Svelte/Astro support. Generated diagnostics have absolute indices which get interpreted from the start of the document instead of the start of the embedded script.

It appears that trying to work around this right now would only introduce more hacks, so I think we better first implement #3334 together with #4726 , in order to get better support for these languages.