Register encoding provider when GetEncoding throws NotSupportedException
#81382
Conversation
|
@dotnet/roslyn-compiler Please review |
| internal readonly bool IsScriptCommandLineParser; | ||
| private static readonly char[] s_searchPatternTrimChars = new char[] { '\t', '\n', '\v', '\f', '\r', ' ', '\x0085', '\x00a0' }; | ||
| internal const string ErrorLogOptionFormat = "<file>[,version={1|1.0|2|2.1}]"; | ||
| private static bool s_registeredEncodingProvider = CodePagesEncodingProvider.Instance == null; |
There was a problem hiding this comment.
How can CodePagesEncodingProvider.Instance be null here? #Resolved
There was a problem hiding this comment.
I do not control behavior of the API. In theory result of the property could be null. We have similar check in other places in our codebase. If it cannot be null, there is no harm in checking it anyway.
| Assert.Equal("Unicode (UTF-8)", parsedArgs.Encoding.EncodingName); | ||
|
|
||
| parsedArgs = DefaultParse(new[] { "/CodePage:1252", "a.cs" }, WorkingDirectory); | ||
| parsedArgs.Errors.Verify(); |
There was a problem hiding this comment.
Would this fail without the fix? #Resolved
There was a problem hiding this comment.
Would this fail without the fix?
Yes, when run on CoreCLR the test fails without the fix with the error from the issue.
|
@dotnet/roslyn-compiler For a second review |
| { | ||
| try | ||
| { | ||
| Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); |
There was a problem hiding this comment.
Why not call RegisterProvider unconditionally before calling GetEncoding? The reason I ask is that my memory was that providing a specific encoding to the compiler was relatively rare. I think we usually don’t get a specific encoding and just assume utf8. And I think utf8 is both the most common encoding (inc ascii) and the recommended encoding.
So if we’re already in an edge case, could we assume that if someone needs a specific code page it might be a non-registered one? #Resolved
There was a problem hiding this comment.
From documentation of the APIs, it is my understanding that calling Encoding.RegisterProvider might overwrite previous setup. So, if the environment was properly setup to support certain encoding, this call might change that setup. I.e. the encoding will be supported but by a different provider. Therefore, I felt that it might make sense to not mess with providers, unless we run into a failure.
There was a problem hiding this comment.
Consider capturing this in a comment, it probably won't be obvious to future readers.
There was a problem hiding this comment.
Def agree. The logic/flow here is complex for me (nested try/catches with gotos). I think this def warrants some explanation on what's going on.
|
@dotnet/roslyn-compiler For a second review |
1 similar comment
|
@dotnet/roslyn-compiler For a second review |
CyrusNajmabadi
left a comment
CyrusNajmabadi
left a comment
There was a problem hiding this comment.
Ah. That helps a lot. Thanks.
4 participants
Fixes #81381