These are just some tweaks I've had on my machine awhile.
- Introduce `PlatformInformation` class to remove several
`RuntimeInformation.IsOSPlatform(...)`. These checks are fairly
efficient, but each [requires in a string
comparison](6ed953a000/src/libraries/System.Private.CoreLib/src/System/OperatingSystem.cs (L122-L134))
and it's easy enough to just do those once and remember the result.
- Replace `OSSkipConditionFactAttribute` with
`ConditionalFactAttribute`. This makes it easier to see what conditions
a test will run under. For example, it's much easier to see that a test
will run on Windows if it's marked with `[ConditionalFact(Is.Windows)]`
rather than `[OSSkipConditionFact(["Linux", "OSX"])]`
* Reduce the amount of telemetry emitted
* Accept code review feedback
* Accept code review feedback (2)
* Change TelemetryScope to NonCopyable struct; if the default constructor is used, _reporter is null so no "report" happens on Dispose. If the _reporter check were removed from Dispose, multiple unittests would fail.
* Undo telemetry-scope-as-struct changes
This change replaces OSSkipConditionFactAttribute a more generally useful ConditionalFactAttribute (and ConditionalTheoryAttribute. This makes it easier to see what conditions a test *should* execute under rather that which conditions it shouldn't.
Thanks to recent changes made by @jjonescz, this pull request moves lots
of unused and unnecessary code from tooling, getting rid of MvcShims in
the tooling layer.
Due to the number of files change, I _strongly_ recommend reviewing
commit by commit.
Part of https://github.com/dotnet/razor/issues/10742
The more I keep plugging away at cohosting code actions, the more I
realise the PR is going to be way too big, so this is the first little
bit I've pulled out from it.
It's mostly mechanical, just pulling document up to the Razor resolve
context, from the individual contexts, changing the endpoint, and then
fixing all the plumbing.
(New PR, from the same commit, from a feature branch so I can keep
working)
Part of https://github.com/dotnet/razor/issues/10742
The next round of changes is to introduce the right abstractions so that
the bulk of the code actions code can be moved to the Workspaces layer
successfully.
At least I think I got it all :D
Reviewing commit at a time probably makes sense, but up to you.
Part of https://github.com/dotnet/razor/issues/10742
This is the final step before actually doing something cohosting
related: Move things to the Workspaces layer and extract services from
the endpoints.
Definitely more work to do on the services to make them usable for
cohosting, but those diffs will at least be easier to view in isolation.
Commit-at-a-time is presumably a much better experience since so many
files moved, and namespaces changed, which I isolated to separate
commits.
The MvcShims defined in tooling are only refernced in the projects located in "src\Razor\test\testapps". However, those projects don't appear to actually ever be built by anything. The source files in the "testapps" projects are used by some of the tooling benchmarks, but that usage doesn't require us to continue building the shims.
rzls imports telemetry by creating an ExportProvider with the path to
devkit telemetry if it's installed and enabled. Unfortunately that means
that dispose is being prematurely called when that provider is torn
down. To help with this two things are done:
1. Make a flush method on ITelemetryReporter
2. Make when flush happens an implementation detail on the specific
providers.
In this case, rzls will flush after the language server host exits. In
other cases IDisposable will be used to flush telemetry (VS and OOP)
* Switch the new lexer off-by-default.
* Add a new document for the lexer breaking changes around pragmas.
* Update comment.
* Feedback
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
---------
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
I noticed some painful NuGet analyzer package upgrades in PR #11048 and
decided to take a look at the issue. I've made the following changes:
- `Roslyn.Diagnostics.Analyzers` is now versioned separately from
`Microsoft.CodeAnalysis.Analyzers`, as they are in
[`dotnet/roslyn`](08243d3826/eng/Directory.Packages.props (L4)).
- I've removed direct references to `MS.CA.BannedApiAnalyzers` since
that reference should flow from `Roslyn.Diagnostics.Analyzers`.
- I've updated the versions of `Microsoft.CodeAnalysis.Analyzers` and
`Roslyn.Diagnostics.Analyzers`
David Wengier
Ankita Khera
Dustin Campbell
dotnet bot
Phil Allen
dotnet-maestro[bot]
Fred Silberberg
Andrew Hall
Chris Sienkiewicz