Roslyn: Include "volatile" in tool tips for volatile fields

[stephentoub]

Version Used:
Version 15.8.0 Preview 1.0 [27627.0.d15.8]

Steps to Reproduce:

1. Add a volatile field to a class.
2. Hover over it.

Expected Behavior:
It would be really helpful if the volatile modifier were shown in the tooltip. When writing low-level concurrent code, knowing whether a field is volatile or not can be really important, and it'd be very helpful if hovering over that field showed the volatility.

Actual Behavior:
The field is volatile:

but volatile is not included in the tool tip.

[sharwell]

Initial design review

This feature went to a preliminary design meeting today. It is still pending acceptance from the full team before it's marked 'up-for-grabs'.

Current behavior

• Fields marked with const are indicated as 'constant' instead of 'field', and would not be changed as part of a feature that only changed the behavior of fields
• Accessibility modifiers are handled by the glyph
• Type modifiers, e.g. ref, are handled as part of the type display
• Other modifiers are ignored

Proposed behavior for 'field'

• Modifiers which are already handled by another display means will continue to be handled exclusively in that manner
• The new implementation adds support for all other modifiers which become a part of the field's signature: static, readonly, volatile
• The new implementation continues to ignore modifiers which don't play into the signature: new, unsafe

Quick Info will display the modifiers before the word 'field' inside the parentheses. For example, (volatile field) or (static readonly field).

Expansion to other symbols

Support for this feature for members other that fields is not required to be included from the start. However, if support does expand beyond fields at all, a new issue should be created for each of the other member types to ensure uniform behavior since a new pattern will be established at that point. The design for each symbol type will vary according to the modifiers supported for that type, but in general should be modeled after the approach described for fields.

[sharwell]

The design from https://github.com/dotnet/roslyn/issues/26947#issuecomment-390831445 was approved by the team, so this is now up for grabs. 😄

[alrz]

Maybe same for static, abstract, sealed, etc for types and methods?

[owlstack]

Is this issue done or can I work on it?

[Neme12]

@owlstack There's an existing PR: #30242