Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1939874
After talking to Dustin this morning I decided to slightly
change tact with cohosting, and not worry about having it be able to
co-exist with the current language server. That means this RPS
regression is easy to fix just by disconnecting the cohost
OpenDocumentGenerator from that system. Yes, that means co-hosting is
now slightly worse, but if we move away from co-existence, then it
matters a lot less, as we no longer expect it to fully work, it just
needs to work enough to let us all get our work done. This PR doesn't
change that.
In reality what this change does is that if cohosting is on, and the old
server is off, then semantic tokens won't be correct for files that were
already open when you stared VS. You have to close and reopen the file.
No big deal IMO
* Add telemetry for time-to-first diagnostic
By adding this Diagnostic kind to our set of capabilities, the VS Win system lights up to gather the time to first diagnostic event, so we can track changes in that time. This will effectively be for our entire diagnostic process, not just syntactic diagnostics as the name of the constants implies.
Adds a simple unittest for the endpoint.
* Fix incrementalism when suppressed:
- Previously when going from unsuppressed -> suppressed we cleared certain caches
- This meant that when going from suppressed -> unsuppressed we were always re compiling every razor file
- Now instead, we produce nothing *until* the generator is unsuppressed, after which we just say that whatever is in the caches is up to date if we're suppressed.
- This ensures no downstream processing takes place when the generator is suppressed, but there is still data to incrementally update when unsuppressed
- We still remove the generated files at the last step when suppressed, so there is no output, but don't have to recompile anything to get the output back again.
This change unifies the IErrorReporter instances used in Razor tooling.
It turns out that there were extras that might cause some errors to not
be reported at all.
### Summary of the changes
1. I've removed the `ErrorReporter.Instance` property. This was a simple
`IErrorReporter` instance that did nothing at all. However, it was
passed into the `ProjectSnapshotManager` used in the language server.
So, any errors from the server's `ProjectSnapshotMangager` wouildn't
actually be reported anywhere useful. Now, the server's
`ProjectSnapshotManager` will use the correct `IErrorReporter` instance,
which reports errors to an `ILogger`.
2. `IErrorReporter` is no longer a Roslyn workspace service. So,
everyplace that retrieved an instance from the workspace is updated to
import an `IErrorReporter` from the DI host (i.e. MEF in VS, and
MS.Extensions.DependencyInjection in the language server).
3. In VS, because `IErrorReporter` isn't exported as a Roslyn workspace
service, that means that there are no longer _two_ `IErrorReporter`
instances in VS. There's now just the one.
This change unifies the IErrorReporter instances used in Razor tooling.
It turns out that there were extras that might cause some errors to
not be reported at all.
1. I've removed the `ErrorReporter.Instance` property. This was a
simple `IErrorReporter` instance that did nothing at all. However, it
was passed into the `ProjectSnapshotManager` used in the language
server. So, any errors from the server's `ProjectSnapshotMangager`
wouildn't actually be reported anywhere useful. Now, the server's
`ProjectSnapshotManager` will use the correct `IErrorReporter` instance,
which reports errors to an `ILogger`.
2. `IErrorReporter` is no longer a Roslyn workspace service. So,
everyplace that retrieved an instance from the workspace is updated to
import an `IErrorReporter` from the DI host (i.e. MEF in VS, and
MS.Extensions.DependencyInjection in the language server).
3. In VS, because `IErrorReporter` isn't exported as a Roslyn workspace
service, that means that there are no longer _two_ `IErrorReporter`
instances in VS. There's now just the one.
While investigating `ProjectSnapshotManagerDispatcher`, I encountered an
issue with `DocumentVersionCache` where it would never exit an
upgradeable read lock. This pull request fixes that issue and makes
several other changes.
1. `DocumentVersionCache` no longer exposes internal data structures for
unit tests. Instead, it provides a `TestAccessor` to avoid allowing
unfettered access to a dictionary that should only be accessed within a
lock.
2. Tests now use a real dispatcher to modify `ProjectSnapshotManager`,
which exposes the issue fixed in this PR.
3. Asserts have been added to verify that methods are called with the
correct lock being held.
4. Structs are no longer passed around to indicate the lock state. These
were a little broken anyway because they are mutable structs that track
their dispose state. However, if they were disposed by an inner method,
the dispose state wouldn't be observed by an outer call because the
structs were passed by value.
Since I've moved some code around, it might be helpful to review
commit-by-commit.
Unified settings is an async package, which means any service it provides has to be loaded asynchronously or incurr a JTF.Run. Since MEF constructors are free threaded, this can cause a block. Use async hook up of change events to mitigate any threading concerns
JSON.NET is no longer used by the majority of Razor product code. The
only components that use NewtonSoft.Json are LiveShare, benchmarks, and
the testing infrastructure. So, I've moved the JSON serialization
support code into a shared project that is linked into the appropriate
places, rather than compiled into `ProjectEngineHost`.
Microsoft.DotNet.Arcade.Sdk
From Version 8.0.0-beta.23620.2 -> To Version 8.0.0-beta.24059.4
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Add tests
* Handle nested type parameters
* Add more tests
* Find type parameters in globally qualified name
* Test `dynamic`
* Keep only type parameters defined by the component
* Add comments
David Wengier
David Wengier
Phil Allen
Chris Sienkiewicz
Dustin Campbell
dotnet-maestro[bot]
dotnet bot
Andrew Hall
Jan Jones
dotnet-maestro[bot]
Alexander Köplinger