Emit opted-in string literals into data section as UTF8 #76036
Conversation
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
jjonescz
force-pushed
the
DataSectionStringLiterals
branch
from
16f5293 to
43aa343
Compare
jjonescz
force-pushed
the
DataSectionStringLiterals
branch
from
43aa343 to
e9e701d
Compare
src/Compilers/Core/Portable/CodeGen/PrivateImplementationDetails.cs
Outdated
Show resolved
Hide resolved
|
@jjonescz Please add details how do we achieve the goal: what artifacts are getting generated, what APIs are needed and how they are used, what compilation phases/layers are involved and how, etc. Basically, I think we need something like an implementation speclet for the compiler feature. #Closed |
|
I stopped reviewing the PR because I think first we need to agree on the implementation strategy and have a speclet to review against. #Closed |
|
@AlekseyTs thanks for the review. Sounds like a good idea to get a spec reviewed first. Opened a separate PR for that: #76139 #Closed |
|
@jjonescz The current PR title: "Add feature flag for emitting string literals into data section as UTF8" sounds like the only thing this PR is doing is adding a flag. I suggest to adjust the title to reflect the main goal/purpose of the PR, which I think is to store values of string literals as Utf-8 encoded bytes in a blob, etc. By comparison to that, the feature flag is a minor detail, which, I think, can be dropped from the title if its length becomes too big. #Closed |
jjonescz
changed the title
src/Compilers/Core/Portable/CodeGen/PrivateImplementationDetails.cs
Outdated
Show resolved
Hide resolved
|
@cston PTAL #Resolved |
src/Compilers/Core/Portable/CodeGen/PrivateImplementationDetails.cs
Outdated
Show resolved
Hide resolved
src/Compilers/Core/Portable/CodeGen/PrivateImplementationDetails.cs
Outdated
Show resolved
Hide resolved
src/Compilers/Core/Portable/CodeGen/PrivateImplementationDetails.cs
Outdated
Show resolved
Hide resolved
src/Compilers/Core/Portable/InternalUtilities/StringExtensions.cs
Outdated
Show resolved
Hide resolved
|
/backport to /refs/release/dev17.3 |
|
Started backporting to /refs/release/dev17.3: https://github.com/dotnet/roslyn/actions/runs/12818583301 |
|
@jaredpar an error occurred while backporting to "/refs/release/dev17.3", please check the run log for details! Error: The specified backport target branch "/refs/release/dev17.3" wasn't found in the repo. |
|
/backport to /release/dev17.13 |
|
Started backporting to /release/dev17.13: https://github.com/dotnet/roslyn/actions/runs/12818638613 |
|
@jaredpar an error occurred while backporting to "/release/dev17.13", please check the run log for details! Error: The specified backport target branch "/release/dev17.13" wasn't found in the repo. |
|
/backport to /refs/release/dev17.13 |
|
Started backporting to /refs/release/dev17.13: https://github.com/dotnet/roslyn/actions/runs/12818690111 |
|
@jaredpar an error occurred while backporting to "/refs/release/dev17.13", please check the run log for details! Error: The specified backport target branch "/refs/release/dev17.13" wasn't found in the repo. |
|
/backport to release/dev17.13 |
|
Started backporting to release/dev17.13: https://github.com/dotnet/roslyn/actions/runs/12818749822 |
Spec: #76139
When this opt-in feature flag is enabled by users, string literals with length over the configured threshold are emitted into data section of the PE file, hence allowing users to overcome the "error CS8103: Combined length of user strings used by the program exceeds allowed limit."
VB support is not implemented in this PR, could be added in the future if there's demand.
I've manually tried this on our unit tests (e.g., Emit2 compiled standalone resulted in significantly smaller file size due to the use of UTF8 instead of UTF16; run time was the same; combining Emit2 and Emit3 into one assembly worked without emit errors). It was also tested on aspnetcore benchmarks and that didn't reveal any significant runtime/build perf changes.
Main motivation for this feature are Razor projects which can accumulate lots of string literals over time (due to how
.razorfile compilation works) and then customers are one day hit with this error without any prior warnings (imagine they are fixing a small bug and suddenly they cannot compile anymore without refactoring their codebase into multiple projects).