Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update LSP Protocol Types #73911

Merged
merged 50 commits into from
Aug 20, 2024
Merged

Update LSP Protocol Types #73911

merged 50 commits into from
Aug 20, 2024

Conversation

mhutch
Copy link
Member

@mhutch mhutch commented Jun 9, 2024

Updates all LSP Protocol types to match the current 3.17 spec. Improves documentation, fixes some minor issues, and adds lots of missing types, properties and methods.

I submoduled Roslyn in the MSBuild Editor repo so I would have definitions to use with CLaSP. After running into some missing things and having to replace some of the definitions locally, I figured the best solution for long-term maintenance would be to update all the definitions to fully cover the spec and contribute them back.

It would be great if these definitions could be included in the CLaSP source package but let's have that discussion separately.

Because of the large amount of changes, I have broken this up into smaller atomic commits structured so that they can be reviewed independently.

I have made a few minor formatting changes and moved a couple files to subdirectories where it made sense together with other changes I was making. These are some bigger changes I'd like to make, such as moving completion types to a Completion directory, switching existing code to file scoped namespaces, and changing properties to required and init, but I'll do those in later PRs if they're acceptable.

Marking as draft as I have not yet checked whether I need to update other Roslyn code to track the handful of API changes I made.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead labels Jun 9, 2024
@dotnet-policy-service dotnet-policy-service bot added the Community The pull request was submitted by a contributor who is not a Microsoft employee. label Jun 9, 2024
Copy link
Member

@dibarbet dibarbet left a comment

Choose a reason for hiding this comment

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

These are some bigger changes I'd like to make, such as moving completion types to a Completion directory, switching existing code to file scoped namespaces, and changing properties to required and init, but I'll do those in later PRs if they're acceptable.

I don't remember - is switching to required a binary breaking change? I think switching to init only would be, so we'd have to be careful about that one.

Otherwise, looks good, some minor comments here and there, but overall great! Thanks for the changes!!

set;
}
[JsonPropertyName(Methods.PartialResultTokenName)]
[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason to put these on the interface definitions? I might be wrong but I don't think the attributes are inherited by the implementations

Copy link
Member Author

Choose a reason for hiding this comment

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

The main reason I did this was to make it easy to copy/paste when implementing the interface 😄

[JsonPropertyName(Methods.WorkDoneTokenName)]
[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
public IProgress<VSInternalDiagnosticReport[]>? WorkDoneToken { get; set; }
public IProgress<WorkDoneProgress> WorkDoneToken { get; set; }
Copy link
Member

Choose a reason for hiding this comment

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

Interesting - I don't know if we even use the WorkDoneProgress type here. I think it only uses partial result version. Not opposed to fixing this 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.

I'm pretty sure the previous WorkDoneProgress impl was plain wrong, so I'd be surprised if it was being used successfully

[JsonDerivedType(typeof(WorkDoneProgressBegin), "begin")]
[JsonDerivedType(typeof(WorkDoneProgressReport), "report")]
[JsonDerivedType(typeof(WorkDoneProgressEnd), "end")]
[JsonPolymorphic(TypeDiscriminatorPropertyName = "kind")]
Copy link
Member

Choose a reason for hiding this comment

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

didn't know you could do this. interesting!

Copy link
Member Author

Choose a reason for hiding this comment

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

Neither did I before this, so I hope it works 😄

/// Title of the progress operation. Used to briefly inform about the kind of operation being performed.
/// Examples: "Indexing" or "Linking dependencies".
/// </summary>
[JsonPropertyName("title")]
Copy link
Member

Choose a reason for hiding this comment

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

I suspect we're not super consistent here, but ideally we'd mark new non-nullable properties with JsonRequired as well

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup I added a bunch of missing JsonRequired to existing members too but I may have missed a few

/// </summary>
[JsonPropertyName("markdown")]
[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
public MarkdownClientCapabilities Markdown { get; init; }
Copy link
Member

Choose a reason for hiding this comment

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

Should be nullable I think

/// The actual workspace folder change event.
/// </summary>
[JsonPropertyName("event")]
public WorkspaceFoldersChangeEvent Event { get; init; }
Copy link
Member

Choose a reason for hiding this comment

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

jsonrequired

/// A Uri like `file` or `untitled`.
/// </summary>
[JsonPropertyName("scheme")]
public string? Scheme { get; init; }
Copy link
Member

Choose a reason for hiding this comment

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

jsonignore

/// The actual file operation pattern.
/// </summary>
[JsonPropertyName("pattern")]
public FileOperationPattern Pattern { get; init; }
Copy link
Member

Choose a reason for hiding this comment

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

jsonrequired

/// </list>
/// </summary>
[JsonPropertyName("glob")]
public string Glob { get; init; }
Copy link
Member

Choose a reason for hiding this comment

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

jsonrequired

/// The actual filters.
/// </summary>
[JsonPropertyName("filters")]
public FileOperationFilter[] Filters { get; init; }
Copy link
Member

Choose a reason for hiding this comment

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

jsonrequired

@mhutch mhutch force-pushed the lsp-protocol-types branch 3 times, most recently from 70ede42 to 8503877 Compare August 15, 2024 16:30
Copy link

Azure Pipelines successfully started running 3 pipeline(s).

Copy link
Member

@dibarbet dibarbet left a comment

Choose a reason for hiding this comment

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

I think I'm good with this (as long as CI passes). One small comment. I didn't go through every file with a fine toothed comb though.

@@ -22,7 +22,7 @@ namespace Microsoft.CodeAnalysis.LanguageServer.Handler
{
[ExportCSharpVisualBasicStatelessLspService(typeof(FindAllReferencesHandler)), Shared]
[Method(LSP.Methods.TextDocumentReferencesName)]
internal sealed class FindAllReferencesHandler : ILspServiceDocumentRequestHandler<LSP.ReferenceParams, LSP.SumType<LSP.VSInternalReferenceItem, LSP.Location>[]?>
internal sealed class FindAllReferencesHandler : ILspServiceDocumentRequestHandler<VSInternalReferenceParams, LSP.SumType<VSInternalReferenceItem, LSP.Location>[]?>
Copy link
Member

Choose a reason for hiding this comment

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

I think I'd rather leave the handler definitions as the base type where possible

@mhutch mhutch force-pushed the lsp-protocol-types branch 2 times, most recently from c40f668 to 8b2ab62 Compare August 19, 2024 21:17
@mhutch
Copy link
Member Author

mhutch commented Aug 20, 2024

@dibarbet i finally got it green!

@dibarbet dibarbet merged commit 2543698 into dotnet:main Aug 20, 2024
25 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Aug 20, 2024
@dibarbet dibarbet modified the milestones: Next, 17.12 P2 Aug 26, 2024
phil-allen-msft added a commit to dotnet/razor that referenced this pull request Aug 28, 2024
Fixes integration test failures in Find All References.

Roslyns LSP types got much more spec compliant in
dotnet/roslyn#73911 and we were never sending
the `Context` property in our request, so deserialization failed on
their end.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Infrastructure Community The pull request was submitted by a contributor who is not a Microsoft employee. untriaged Issues and PRs which have not yet been triaged by a lead VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants