roslyn
roslyn copied to clipboard
dotnet
Add support for more StringSyntaxAttribute syntaxes
.NET 7 adds the new [StringSyntax(...)] attribute, which Roslyn is now already recognizing in support of the StringSyntaxAttribute.DateTimeFormat/Regex/Json values. https://github.com/dotnet/runtime/pull/67621 is rounding out the named syntaxes on the attribute with an additional set, while also attributing all relevant parameters across the core libraries with these:
- [ ] "CompositeFormat" - a composite format string (https://docs.microsoft.com/en-us/dotnet/standard/base-types/composite-formatting#composite-format-string), like the one passed to string.Format / StringBuilder.AppendFormat. It'd be great if syntax coloring could be applied to these, as is done for interpolated strings, and ideally syntax validation for composite format strings with invalid syntax (the latter could also be done as an analyzer).
- [ ] "DateOnlyFormat" / "TimeOnlyFormat" - same as "DateTimeFormat", but with only the date-related and time-related specifiers, relatively. It'd be great if similar IntelliSense could be provided for these as is provided for "DateTimeFormat", just with only the relevant items filtered.
- [ ] "EnumFormat" - a specifier used for how an enum is formatted (https://docs.microsoft.com/en-us/dotnet/standard/base-types/enumeration-format-strings). IntelliSense could do something similar to that for "DateTimeFormat", and warn when an unsupported option is used.
- [ ] "GuidFormat" - a specifier used for how a Guid is formatted or parsed (https://docs.microsoft.com/en-us/dotnet/api/system.guid.system-iformattable-tostring?msclkid=b56bc8efb52c11ecbb60280f9226ae5d&view=netstandard-1.6#parameters). IntelliSense could do something similar to that for "DateTimeFormat", and warn when an unsupported option is used.
- [ ] "NumericFormat" - a specifier used for how one of the many numerical types is formatted (https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings?msclkid=027a8ed2b52d11ecad542115310f6ce9). IntelliSense could do something similar to that for "DateTimeFormat".
- [ ] "TimeSpanFormat" - a specifier used for how to format TimeSpan instances (https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-timespan-format-strings)
- [ ] "Uri" - URLs. Syntax coloring and validation could be employed.
- [ ] "Xml" - XML. Syntax coloring and validation could be employed.
cc: @CyrusNajmabadi
I would be fine with support being added for all of these. The hope of roslyn though would be that we don't own most of these though. The purpose of my efforts to expose extensibility points here is so htat others can own this.
Related (also cc. @teo-tsirpanis), would it be possible to also support syntax highlight for languages that the IDE already supports? Essentially what we get with the 3 backticks + language id on GitHub/Discord/etc., which could work whenever the language id (ie. the file extension) is one that VS already has support for.
For instance, if I had a [StringSyntax("cpp")] parameter (or "cs", or whatever), as long as that id was one which would give me syntax highlight if I was to just open a file with that extension in VS, I would expect the same to apply to the literal as well.
Example scenario: I have a [D2DPixelShaderSource] attribute in ComputeSharp you can use like this:
The parameter of that [D2DPixelShaderSource] has "hlsl" as [StringSyntax] argument. Given I do get syntax highlight whenever I open an .hlsl file in VS, I would expect the same to apply here as well. Would this be doable? I mean VS evidently does have logic to do syntax highlight based on the file extension, but it be doable to plug that through here as well? 🙂
NOTE: @CyrusNajmabadi if this is out of scope for this issue let me know and I can open a separate one 😄
Right, but I guess what I'm wondering is: if the identifier is an extension that VS already has support for, couldn't this just work out of the box just like when you open a file, without the need for consumers to install any plugins or really anything at all? 😄 It would really be convenient especially when using identifiers that are widely used and with built-in support in VS.
@CyrusNajmabadi by "plugins" you mean Visual Studio extensions? What I would like is to allow library authors to define a custom language syntax with possible tooltips within the assembly, for example with an embedded resource file that gets read by IDEs. It would enable writing custom languages for both VS and VSCode. And of course also recognize the languages VS already knows as @Sergio0694 said.
Right, but I guess what I'm wondering is: if the identifier is an extension that VS already has support for, couldn't this just work out of the box just like when you open a file
Anything is possible. A core difficulty is that these are not the same languages. For example , in a c# string you have escape sequences that the underlying language will not understand.
It would really be convenient especially when using identifiers that are widely used and with built-in support in VS.
Sure. But someone has to pay for all that work. :-)
For context, json and regex was multiple weeks of work to try to get those working. Now someone has to test and validate every language embedded in c#
Just an idea (feel free to ignore). Should something like this be possible:
[StringSyntax("lang_de")]
[StringSyntax("lang_en-us")]
so IDEs can offer context dependent spell checking?
I don't think it would be of much value. Localized strings should be in a resource file either way.
Hi, I'm working on a free Visual Studio extension that adds support for GraphQL syntax. The extension is called GraphQLTools and it is currently in preview. The source code is available here; I hope that it could be of help to people interested in extending the feature to more syntaxes. Writing a Visual Studio extension is quite challenging because the documentation is not that exhaustive and we would love to be able to write plugins for the StringSyntaxAttribute feature in a more standardized way.
