Use narrow type for string parsing patterns

[dhruvmanila]

Summary

This PR adds a new enum type StringType which is either a string literal, byte literal or f-string. The motivation behind this is to have a narrow type which is accepted in concatenate_strings as that function is only applicable for the mentioned 3 types. This makes the code more readable and easy to reason about.

A future improvement (which was prototyped here and removed) is to split the current string literal pattern in LALRPOP definition into two parts:

1. A single string literal or a f-string: This means no checking for bytes / non-bytes and other unnecessary compution
2. Two or more of string/byte/f-string: This will call the concatenate_strings function.

The reason for removing the second change is because of how ranges work. The range for an individual string/byte is the entire range which includes the quotes as well but if the same string/byte is part of a f-string, then it only includes the range for the content (without the quotes / inner range). The current string parser returns with the former range.

To give an example, for "foo", the range of the string would be 0..5, but for f"foo" the range of the string would be 2..5 while the range for the f-string expression would be 0..6. The ranges are correct but they differ in the context the string constant itself is being used for. Is it part of a f-string or is it a standalone string?

Test Plan

cargo test

[dhruvmanila]

Current dependencies on/for this PR:

• main
  • PR Add a NotebookError type to avoid returning Diagnostics on error #7035
    • PR Make SourceKind a required parameter #7013
      • PR Add support for the new f-string tokens per PEP 701 #6659
        • PR Add support for parsing f-string as per PEP 701 #7041
          • PR Use narrow type for string parsing patterns #7211 👈
            • PR Disallow non-parenthesized lambda expr in f-string #7263
              • PR Fix curly brace escape handling in f-strings #7331
                • PR Update Indexer to use new f-string tokens #7325
                  • PR Detect noqa directives for multi-line f-strings #7326
                  • PR Update F541 to use new f-string tokens #7327
                  • PR Update Stylist quote detection with new f-string token #7328
                  • PR Update W605 to check in f-strings #7329

This comment was auto-generated by Graphite.

[codspeed-hq]

CodSpeed Performance Report

Merging #7211 will degrade performances by 9.7%

_{⚠️ No base runs were found}

_{Falling back to comparing dhruv/fstring-parser-2 (5f17468) with main (04183b0)}

Summary

❌ 8 regressions
✅ 17 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	dhruv/fstring-parser-2	Change
❌	lexer[numpy/globals.py]	233.2 µs	252.9 µs	-7.8%
❌	lexer[large/dataset.py]	9.8 ms	10.7 ms	-8.4%
❌	lexer[pydantic/types.py]	4.1 ms	4.6 ms	-9.7%
❌	parser[numpy/ctypeslib.py]	12.4 ms	12.7 ms	-2.31%
❌	parser[large/dataset.py]	68.4 ms	70 ms	-2.29%
❌	lexer[numpy/ctypeslib.py]	2 ms	2.1 ms	-7.71%
❌	lexer[unicode/pypinyin.py]	620.2 µs	673.4 µs	-7.89%
❌	parser[unicode/pypinyin.py]	4.3 ms	4.4 ms	-2.53%