Merge main into VBOverloadResolutionPriority #75955

…semicolons

…turn its location

…ed api at a later point

…ticModelCaching.cs Co-authored-by: Todd Grunke <[email protected]>

…nto syncWork

…etector.cs

…sNajmabadi/roslyn into embeddedClassificationLater

…doesn’t include the target struct (a cycle at the end of the path) (#75702) Fixes #66844

Fixes #75871.

#75867) * Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20241111.2 Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 10.0.0-alpha.1.24558.1 -> To Version 10.0.0-alpha.1.24561.2 * Failed to perform coherency update for one or more dependencies. --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

)

…neratedCode

…aught by speedometer (#75895) The change in #75756 was incorrect when the existing number of items is between SegmentSize / 2 (inclusive) and SegmentSize (exclusive). In this case, the size of the newCapacity would end up as exactly the requested capacity, causing a potentially O(n^2) allocation growth pattern if caller was just increasing the requested capacity by one from it's current size. The fix is just to handle that case directly, and if the existing size falls into that range, to simply set the desired newCapacity to the SegmentSize.

…neratedCode

…d used in a foreach

… rude edits (#75874)

…ve async listener in queue

…semicolons (#75632)

Follow up to #75460 Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2288477 When I looked at the code I thought "Who would want to map a span, and then not use the mapped span?!". Turns out the answer is "aspx files".

* Handle directives in trailing trivia * Revert the change and improve tests * Attach trailing directives as skipped tokens trivia * Update tests * Parse as bad directive trivia * Simplify tests * Remove trailing parameter * Parse as skipped tokens trivia * Carry trivia over * Wrap trivia in a token * Put text into one token * Simplify width logic * Refactor to simplify the code * Add more tests * Pass `false` and explain

…d used in a foreach (#75903) Fixes #57470

…ty (#75904)

…o use a collection expression. (#75897)

…ionLater

) SerializableClassifiedSpans.Dehydrate was previously taking in an ImmutableArray, causing several callers to allocate. Instead, have it take in a SegmentedList, which several of the callers already have, and if not, a pooled instance can be obtained and populated. ClassifiedSpan[] shows up as 5.4% of allocations in our CodeAnalysis process in the platform's scrolling speedometer test.

…s to clear (#75841)

…ed api at a later point (#75875)

)

…edometer (#75912) TokenPairWithOperations[] accounts for 2.4% of total allocations in the test. Locally reproducing this demonstrated that there is usually a small number of tokens that are added, but occasionally a much larger token count is added. Doing a single shot allocation in the case where we are significantly increasing the SegmentedList size is more efficient than growing organically by adding single items.

Also changes GoToTypeDefinition handler's behavior to lookup the symbol's type and return its location https://github.com/user-attachments/assets/538d0e32-38c0-45c5-897c-a9510664fa1a

…ve async listener in queue (#75907) Should resolve https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2224584 Optprof web application tests have been failing for a while in VS. Tim tracked down the issue to an async listener introduced in #74530 The never completing listener were requests for workspace diagnostics. This is actually expected for workspace diagnostics requests, as they are held open indefinitely if nothing changes (see https://github.com/dotnet/roslyn/blob/main/src/LanguageServer/Protocol/Handler/Diagnostics/AbstractWorkspacePullDiagnosticsHandler.cs#L94). So as long as workspace diagnostics requests function this way, it is easy to get into a situation where there are async listeners that never complete. The queue async listener was introduced to ensure that unit tests could reliably verify if the NFW handler was called (as handling the exception happened after the response was returned to the client). To resolve this issue I did a couple things 1. Move reporting NFW for request exceptions into the telemetry reporting scope. Importantly this scope is called before the result is sent back to the client. This allows unit tests to simply wait for the request to complete before checking if the NFW handler was called (no need for an async listener). 2. Removing the async listener from the queue now that no unit tests need to wait for an action to occur in the queue. TODO - validate optprof

…75891)

…Name()` implementation (#75764)

…112.13 (#75915) Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk From Version 9.0.0-beta.24516.2 -> To Version 9.0.0-beta.24562.13 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* Update .NET 9 runtime for single machine CI job * Use regular pool

…-multi-line-raw-string

…baseline update (#75934)

…75648)

* Add runtime async design doc Adding an initial design document for runtime async. I'm not making a branch for this yet so I don't have to worry about keeping it up to date until we're actually ready to start implementation work; that should begin soon, but I think getting this document into `main` and starting collaboration with the runtime and debugger folks will help that proceed. * Remove incorrect IL steps * Add more examples and updates the runtime document. * Add another open question * Add more translated C# samples * Feedback and more scenarios * Remove PR link * Add note about potential hoisted local cleanup

Inspired by a test in #75862.

Client side PR - dotnet/vscode-csharp#7791 Implements support for refreshing source generated files provided by LSP. Refresh notifications are sent to the client based on workspace changes that may affect source generated files. To handle the overreporting of refresh notifications, I also implemented resultId based support in the get text handler - it will now avoid re-sending the entire text to the client if nothing has changed. ![sg_refresh](https://github.com/user-attachments/assets/065a8532-56c7-4e45-a559-0a451d37697a)

…ions from VS shell (#75815) * Reduce IVsFreeThreadedFileChangeEvents2.DirectoryChangedEx2 notifications from VS shell While looking into another FileWatcher issue, I noticed that we were getting more notifications from shell on directory changes than I would have expected. It turns out this is because we don't currently combine WatchDirectory operations as we do WatchFile/UnwatchFile/UnwatchDirectories. This is generally the desired behavior as vs shell doesn't support multiple directories being supported by a single notification. However, they do support multiple filters on the same directory, and this is exactly the case that we usualy experience when processing a batch of WatcherOperations. This PR simply allows combining of directory watch notifications for the same directory (and sink), keeping track of the combined set of filters that all requests had. Note that this PR also changed the mergability of WatchFiles by only allowing merging if the sinks are the same. I don't have context to be completely confident the prior behavior is a bug, but it sure seems wrong.

…tion of textchanges (#75928) * Send over the new sourcetext's content checksum when sending notification of textchanges Calculation of this on the server was taking quite a bit of CPU (about 11.6% in the scrolling speedometer during the typing scenario). Instead, pass this data over as part of the text change notification, similar to what SerializableSourceText's serialization does.

Co-authored-by: Omar Bonnet <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge main into VBOverloadResolutionPriority #75955

Merge main into VBOverloadResolutionPriority #75955

Commits on Aug 14, 2024

Commits on Aug 16, 2024

Commits on Aug 30, 2024

Commits on Oct 1, 2024

Commits on Oct 2, 2024

Commits on Oct 25, 2024

Commits on Oct 27, 2024

Commits on Nov 4, 2024

Commits on Nov 5, 2024

Commits on Nov 7, 2024

Commits on Nov 8, 2024

Commits on Nov 12, 2024

Commits on Nov 13, 2024

Commits on Nov 14, 2024

Commits on Nov 15, 2024

Commits on Nov 16, 2024

Commits on Nov 18, 2024