- 25 1月, 2020 1 次提交
-
-
由 Andy Gocke 提交于
The synthesized constructor assigns the properties, if they are synthesized properties. The properties are synthesized only if no conflicting member already exists in the class.
-
- 18 1月, 2020 7 次提交
-
-
由 Julien Couvreur 提交于
-
由 Andy Gocke 提交于
Capturing lambdas should be avoided in core compiler code as they generate excess allocations Fixes #41054
-
由 Fred Silberberg 提交于
* Insert correct `WithNullableContext` binder into the binder chain to ensure speculative models return correct information based on speuclation location. * Refactor Nullable context options to rely on an enum instead of two bools. Break out the BuckStopsHereBinder's code to allow sharing. Fix binder ordering issue for TryGetSpeculativeSemanticModelForMethodBody. * Make NullableContextState.State a byte for space.
-
由 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 次提交
-
-
由 Andy Gocke 提交于
This just adds a synthesized symbol (no body) for the constructor. Preliminary spec work at https://github.com/dotnet/csharplang/pull/3076
-
由 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`
-
由 Sam Harwell 提交于
-
- 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 5 次提交
-
-
由 Charles Stoner 提交于
-
由 Andy Gocke 提交于
This will cause local Visual Studio and VS Code test runners to run under CoreCLR by default. This will only affect tests which are multi-targeted, which today only includes the compiler unit tests.
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Julien Couvreur 提交于
-
- 12 1月, 2020 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 11 1月, 2020 2 次提交
-
-
由 Sam Harwell 提交于
-
由 Julien Couvreur 提交于
-
- 10 1月, 2020 6 次提交
-
-
由 Rikki Gibson 提交于
-
由 Rikki Gibson 提交于
-
由 Charles Stoner 提交于
-
由 Jared Parsons 提交于
-
由 Rikki Gibson 提交于
This reverts commit 6b22ff18.
-
由 Rikki Gibson 提交于
-
- 09 1月, 2020 8 次提交
-
-
由 Fredric Silberberg 提交于
-
由 Jared Parsons 提交于
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Sam Harwell 提交于
-
由 Jared Parsons 提交于
-
由 Andy Gocke 提交于
* Improve nullable analysis of local functions This design tries to meld better analysis of nullable reference types in local functions with performance. To keep the common case one pass, local functions are analyzed using the starting state that is an intersection of all the states before its usages (calls, delegate conversions, etc), but the results of variables made nullable or non-nullable inside the local function do not propagate to the callers. * Respond to PR comments
-
由 Julien Couvreur 提交于
-
- 07 1月, 2020 1 次提交
-
-
由 Jared Parsons 提交于
-