- 31 1月, 2020 4 次提交
-
-
由 Jared Parsons 提交于
Had to clean up a few nullable annotations now that we are compiling agaist `netcoreapp3.1` and hence get the full value of the framework annotations. This is also problematic though because there are now two places where the compiler can see nullable attributes that are directly used by the developer. For example `NotNullWhenAttribute`. This is both defined in our assemblies for non-netcoreapp target frameworks and provided by the SDK when targeting `netcoreapp3.1`. This causes a problem for assemblies which have the following characteristics: 1. Target `netcoreapp3.1` 1. Reference an assembly targeting `netstandard2.0` which uses our nullable attributes definition 1. Has IVT into (2) above These properties essentially define all of our unit test assemblies. In that environment it's not possible to use nullable attributes in code because the compiler can't disambiguate which definition of `NotNullWhenAttribute` to use. This meant I had to temporarily remove a few attributes until we can complete #40766.
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Decided to remove the property based approach to specifying a target framework to just specifying `netcoreapp3.1` directly. The reason for this is the following: The advantage of the property is it makes it "easy" to change to a new target framework in the future. That benefit is actually pretty minimal. A simple find and replace operation is **extremely** effective in our code base (it's less key strokes than this message). Hence the benefit is minimal. The downside of the property is that our code doesn't look like customer code. Or rather it diverges from the practices that we publish. In general I prefer to keep our code as standard as possible unless there is a good reason to deviate. There just doesn't seem to be one here.
-
由 Jared Parsons 提交于
Change Roslyn to target netcoreapp3.1 when building .NET Core assets. Previously the code targetted a mix of netcoreapp2.1 and netcoreapp3.0. The mix is due to default interfaces only being supported on netcoreapp3.0 and hence our testing needed to use that. Yet at the same time we were required to ship the compiler in SDKS that targetted netcoreapp2.1. Now we can universally target netcoreapp3.1.
-
- 29 1月, 2020 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Move "is telemetry allowed" flag to DiagnosticAnalyzerInfoCache * Clean up DiagnosticService * Fixes * Remove analyzer exception telemetry reporting. * Remove reporting analyzer exceptions from SupportedDiagnostics. The diagnostics will be reported when the compiler runs the analyzer on the compilation. * Remove unused parameter * Clean up analyzer telemetry reporting. * Test fixes * Feedback
-
- 28 1月, 2020 2 次提交
-
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
- 25 1月, 2020 2 次提交
-
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
- 24 1月, 2020 11 次提交
-
-
由 Julien Couvreur 提交于
-
由 Fredric Silberberg 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
- 23 1月, 2020 1 次提交
-
-
由 Jonathon Marolf 提交于
-
- 18 1月, 2020 4 次提交
-
-
由 Sam Harwell 提交于
Addresses 3200MB allocations while analyzing Roslyn.sln.
-
由 Sam Harwell 提交于
Addresses 950MB allocations while analyzing Roslyn.sln.
-
由 Sam Harwell 提交于
Addresses 950MB allocations while analyzing Roslyn.sln.
-
由 Sam Harwell 提交于
Addresses 2400MB allocations while analyzing Roslyn.sln.
-
- 17 1月, 2020 5 次提交
-
-
fix for language code capitalization
-
由 Sam Harwell 提交于
Addresses 680MB allocations analyzing Roslyn.sln.
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
- 16 1月, 2020 3 次提交
-
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
The `SyntaxNodeOrToken` type had four states: 1. It's a `SyntaxNode` 1. It's a `SyntaxToken` 1. It's `default(SyntaxNodeOrToken)` 1. It returns `true` for `IsNode` but `AsNode` returns `null` The fourth state appears to be an accident of implementation. This change removes that state. The one place in the code where this appeared to be an issue is in the implicit conversion from `SyntaxNode?` to `SyntaxNodeOrToken`. In all places where this was used and the value was potentially `null` the caller only used `GetLocation` on the result. Hence the fix is simply to change that API to return `default` instead of the fourth state in the case of `null`
-
- 15 1月, 2020 1 次提交
-
-
由 Tomáš Matoušek 提交于
EnC: Tweak handling of out-of-sync documents to work around source file content inconsistencies (#40947) * Do not block in presence of out-of-sync documents. Instead, ignore any changes made to these documents while debugging until their content matches the source used to build the baseline DLL. * Only check output PDB, not debugger SymReader, for document checksums. Turns out SymReader does not support reading document checksums once EnC changes have been applied. Better handle errors that might occur when validating checksums. Previously some of the errors were not reported as diagnostics. We previously blocked EnC when we observed a source file that is out-of-sync (i.e. its current content does not match the checksum in the originally built PDB). We can however just ignore these files and report a warning that changes made to this file won’t be applied until the file content is reverted back to the state it was when the PDB was built (the file transitions to “matching” state). Once a file is in matching state it can’t change back to another state. We know that we have not applied any change to the code that was compiled from the file because we ignored the file while it was in out-of-sync state. Therefore we know that any changes made from now on can be safely applied to the debuggee. If we can’t determine whether a file matches or not due to error reading the PDB or the source file content we can treat it similarly to out-of-sync file. That is, ignore any changes until we are able to confirm the file matches. That can happen if, e.g. the PDB is temporarily locked by another process and unlocked later. Simplify implementation of GetStatusAsync. Fixes VSO [1051496](https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1051496) ([VS feedback](https://developercommunity.visualstudio.com/content/problem/880533/edits-were-made-which-cannot-be-compiled-stop-debu.html))
-
- 14 1月, 2020 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
- 12 1月, 2020 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 10 1月, 2020 1 次提交
-
-
由 Jared Parsons 提交于
-
- 09 1月, 2020 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Sam Harwell 提交于
-