Skip to content

Update SDK and use 'u8' string literals#41449

Merged
BrennanConroy merged 2 commits intomainfrom
brecon/u8sdk
Apr 30, 2022
Merged

Update SDK and use 'u8' string literals#41449
BrennanConroy merged 2 commits intomainfrom
brecon/u8sdk

Conversation

@BrennanConroy
Copy link
Member

@BrennanConroy BrennanConroy commented Apr 29, 2022

Updated SDK, this brings in a newer compiler with the new 'u8' string literal syntax. Sadly, there are some big breaking changes with the feature that will hopefully be fixed, tracking issue dotnet/roslyn#60644. And required some test code (and one area in product code, CertificateManager) to be updated.

The rest of the changes are to update our ReadOnlySpan<byte> name => new byte[] { ... }; code to use the new 'u8' feature.

Also, folks likely need to update VS for the feature to light up.

Copy link
Contributor

@dougbu dougbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear why we aren't waiting for the new language feature to settle before making changes like this and #41317. What's the rush on either❔

Comment on lines -35 to +36
private static ReadOnlySpan<byte> MimePrefix => new byte[] { (byte)'"', (byte)'=', (byte)'?', (byte)'u', (byte)'t', (byte)'f', (byte)'-', (byte)'8', (byte)'?', (byte)'B', (byte)'?' };
private static ReadOnlySpan<byte> MimeSuffix => new byte[] { (byte)'?', (byte)'=', (byte)'"' };
private static ReadOnlySpan<byte> MimePrefix => "\"=?utf-8?B?"u8;
private static ReadOnlySpan<byte> MimeSuffix => "?=\""u8;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes do look like goodness. However, do they allocate more than the old form (given dotnet/roslyn#60644 and dotnet/csharplang#5983)❔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they shouldn't allocate in these cases.

@BrennanConroy
Copy link
Member Author

It's not clear why we aren't waiting for the new language feature to settle before making changes like this

It's called dogfooding, people have to use a new feature in order to find the issues with it. Also, like you noted, this change makes some of our code look a lot nicer 😃

@dougbu
Copy link
Contributor

dougbu commented Apr 29, 2022

Also, like you noted, this change makes some of our code look a lot nicer 😃

I also noticed a few icky extra casts and the variables that'll be useless once the feature's bugs are fixed.

@BrennanConroy
Copy link
Member Author

Sure, there is one ugly cast in CertificateManager, and a couple tests need a variable now, although the majority of the test changes actually look cleaner IMO, like https://github.com/dotnet/aspnetcore/pull/41449/files#diff-0fceab451ef913bdaa9272f539284c733c1892adc275414eb29250ff5b4b1facR71 we now use the same variable for the input and the expected output in the assert instead of duplicating the value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants