Skip to content

Conversation

@jjonescz
Copy link
Member

@jjonescz jjonescz commented Aug 11, 2025

SymbolDisplay.FormatPrimitive returns null for unsupported types and its documentation always indicated that.
However, the return type was incorrectly marked as non-nullable and this PR fixes that.

@jjonescz jjonescz added the breaking-change https://github.com/dotnet/sdk/blob/main/documentation/project-docs/breaking-change-guidelines.md label Aug 11, 2025
@dotnet-policy-service dotnet-policy-service bot added Needs API Review Needs to be reviewed by the API review council needs-breaking-change-doc-created labels Aug 11, 2025
@jjonescz jjonescz marked this pull request as ready for review August 11, 2025 14:52
@jjonescz jjonescz requested review from a team as code owners August 11, 2025 14:52
static Microsoft.CodeAnalysis.CSharp.LanguageVersionFacts.TryParse(string? version, out Microsoft.CodeAnalysis.CSharp.LanguageVersion result) -> bool
static Microsoft.CodeAnalysis.CSharp.SymbolDisplay.FormatLiteral(char c, bool quote) -> string!
static Microsoft.CodeAnalysis.CSharp.SymbolDisplay.FormatLiteral(string! value, bool quote) -> string!
static Microsoft.CodeAnalysis.CSharp.SymbolDisplay.FormatPrimitive(object! obj, bool quoteStrings, bool useHexadecimalNumbers) -> string!
Copy link
Member

Choose a reason for hiding this comment

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

Is this what the fixer suggested? I thought that when shipped APIs change, we use some kind of REMOVED annotation or similar in the unshipped file. For example, if someone ran the tool to "mark APIs as shipped", we wouldn't want them to get the impression that FormatPrimitive was only just added in this release.

It's possible I am remembering things wrong and this is not a real problem, though.

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, the fixer in VS didn't suggest anything (I'm not sure it can since this is a non-C# file), so I removed it manually. But then the analyzer didn't complain so I thought it's correct 🤷 But you're right, I also remember seeing some **REMOVED** prefix; will investigate more.

Copy link
Member

Choose a reason for hiding this comment

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

The analyzer diagnostics which complain about the PublicAPI files, not matching the API surface in source code, are supposed to have fixers that update the PublicAPI files. However due to them being plain text and not C# getting the fixers to actually run on them I think has broken in the editor at various points.

Copy link
Member Author

Choose a reason for hiding this comment

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

I haven't found any fixer for "removed APIs" - https://github.com/dotnet/roslyn/tree/main/src/RoslynAnalyzers/PublicApiAnalyzers/Core/CodeFixes

But I figured out how to mark as *REMOVED* manually.

class C : I;
```

## `SymbolDisplay.FormatPrimitive` API is now properly nullable annotated
Copy link
Member

Choose a reason for hiding this comment

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

This document is generally used for changes in the compiler's actual output, not API changes. In general, we do not consider nullability fixes to be "breaking", I'm not sure this actually needs this level of documentation.

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

we do not consider nullability fixes to be "breaking"

I guess this means the answer is no. And I can remove the "breaking change" label as well. Thanks.

@jjonescz jjonescz removed breaking-change https://github.com/dotnet/sdk/blob/main/documentation/project-docs/breaking-change-guidelines.md needs-breaking-change-doc-created labels Aug 13, 2025
@jjonescz jjonescz requested a review from 333fred August 13, 2025 11:54
@jjonescz jjonescz merged commit a523b84 into dotnet:main Aug 14, 2025
24 checks passed
@jjonescz jjonescz deleted the format-primitive branch August 14, 2025 09:41
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Aug 14, 2025
@RikkiGibson RikkiGibson modified the milestones: Next, 18.0 P1 Aug 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Compilers Needs API Review Needs to be reviewed by the API review council

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants