Skip to content

Conversation

@am11
Copy link
Member

@am11 am11 commented Dec 3, 2025

No description provided.

@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Dec 3, 2025
@MichalStrehovsky
Copy link
Member

This doesn't remove the conversions. I'm actually already working on removing the conversions (pushed out what I have at #122160). This PR will just introduce unnecessary merge conflicts.

@am11
Copy link
Member Author

am11 commented Dec 3, 2025

This doesn't remove the conversions.

This PR is improving a few places where we were accidentally allocating (calling .ToString() on Utf8String then assigning to Utf8String..) and it isn't regressing anything. It's good to keep allocations explicit to avoid such accidents.

@am11
Copy link
Member Author

am11 commented Dec 8, 2025

@MichalStrehovsky, merged and updated object writer.

@MichalStrehovsky
Copy link
Member

@MichalStrehovsky, merged and updated object writer.

Thank you!

Could you do a pass over these and look at places that do undesirable allocations?

The places that currently use the implicit conversion operator are markers for "unreviewed legacy code". They may or may not be causing excessive allocations and conversions. The places are easy to search for. The places that use the string/byte[] constructors right now are "reviewed". They are known not to cause excessive allocations and we're not going to revisit them as part of the UTF-8 effort anymore.

This PR switches everything to use the string or byte[] constructors. This shakes things up and we can no longer distinguish between things that are done and we're happy with vs things that are not done yet. My preference would be to do this piecemeal and delete the uses of the operator in batches. However if you would like to delete the operator in this PR, I'd like to ask you to go over the places that do excessive allocations and fix them up so that we can maintain the "string or byte[] constructor means we're done here" invariant.

@am11 am11 force-pushed the chore/utf8string-cleanup branch 2 times, most recently from 692389e to 65bcf82 Compare December 14, 2025 17:27
@am11
Copy link
Member Author

am11 commented Dec 14, 2025

@MichalStrehovsky, I’ve reviewed the changes and applied updates in 0fb2c78. If you notice anything that seems off, please let me know. I’ve intentionally left expressions such as Type.Name alone, because these values might include multi-byte characters.

@MichalStrehovsky
Copy link
Member

/azp run runtime-nativeaot-outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@MichalStrehovsky
Copy link
Member

/ba-g I think the globalization issue has a fix in #122480

@MichalStrehovsky MichalStrehovsky merged commit 6cfcaf9 into dotnet:main Dec 22, 2025
117 of 121 checks passed
@am11 am11 deleted the chore/utf8string-cleanup branch December 22, 2025 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-NativeAOT-coreclr community-contribution Indicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants