- 27 6月, 2020 4 次提交
-
-
由 Julien Couvreur 提交于
-
由 Tomáš Matoušek 提交于
-
由 Chris Sienkiewicz 提交于
* Introduce LanguageVersion.CSharp9 * Limit netcoreapp3.0, 3.1 and netstdard 2.1 to C# 8.0 * Map CSharp9 to language version preview * Default to CSharp9 for netcoreapp5.0 * Add Tests
-
由 msftbot[bot] 提交于
Include line numbers in Integration Test stack traces
-
- 26 6月, 2020 25 次提交
-
-
由 Sam Harwell 提交于
Fix failure to reuse pooled connections
-
由 msftbot[bot] 提交于
Updates the option page type GUID to match the one in pkgdef
-
由 Tomas Matousek 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
Track unrooted symbols in HashSet instead of ConditionalWeakTable
-
https://github.com/dotnet/roslyn由 dotnet-maestro[bot] 提交于
Microsoft.Net.Compilers.Toolset From Version 3.7.0-4.20314.5 -> To Version 3.7.0-4.20319.6 Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
-
由 Jason Malinowski 提交于
Fix descriptions for XMLDoc Triple Apostrophes in some languages.
-
由 Andy Gocke 提交于
Records need to provide a new form of source property symbol with different syntax. This PR extracts a new base class to try to share as much code as possible with the existing SourcePropertySymbol and the SynthesizedRecordPropertySymbol.
-
由 Fred Silberberg 提交于
-
由 Sam Harwell 提交于
Remove unnecessary conditional compilation
-
由 Sam Harwell 提交于
-
由 msftbot[bot] 提交于
Refactor IDE open file diagnostic analysis + some perf improvements
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
由 AlekseyTs 提交于
Move SourceOrdinaryMethodSymbol functionality that is not syntax specific into a new base class. (#45424) This work is related to #45296.
-
由 msftbot[bot] 提交于
Don't fetch output paths for Intellisense projects
-
由 Jason Malinowski 提交于
Document and test how CanApplyParse/CompilationOptions works
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
-
-
由 Neal Gafter 提交于
Fixes #375
-
由 Fredric Silberberg 提交于
-
- 25 6月, 2020 11 次提交
-
-
由 Manish Vasani 提交于
Add new public APIs to CompilationWithAnalyzers to fetch syntax and s…
-
由 Allison Chou 提交于
Fix for incorrect IDE0007 implicit type diagnostic being reported in switch expressions
-
由 Fredric Silberberg 提交于
-
由 Jason Malinowski 提交于
-
由 Allison Chou 提交于
-
由 Ankita Khera 提交于
Bug 11510
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
Remove the OperationConstantValue wrapper type and push the WeakReference logic into string specialized ConstantValue implemention. Optimized internal calls to `ConstantValue.HasValue` to get the underlying instance to avoid realizing strings for these cases.
-
由 Manish Vasani 提交于
-
由 Jason Malinowski 提交于
Web projects based on the legacy project system use special projects called "intellisense projects" which are fake projects that are used to act as a container for some contained languages. These are usually created with the same IVsHierarchy as a regular project, which has an unfortunate side effect. We get our build output paths from the IVsHierarchy, so it would mean both the "real" project and the Intellisense project would get the same output path. In VS 2017, we would use that build output path to potentially convert metadata references on disk back to project references. The ambiguous path was problematic, but there was a bug: if the metadata reference was converted to a project reference when there was only one project (i.e. before you opened the file with a contained document), we converted it but then left that project converted; if a later project came along and outputted to the same output path the connection would be left around. If the reference got added after the duplicate project, it'd potentially stay a metadata reference. In VS 2019, we rewrote the whole system that did metadata-reference-to-project-reference conversion, and this time wrote it "correctly" in that the end state didn't depend on the order of events you took to get there; if you have two projects outputting the same path, then we just don't convert a metadata reference to a project reference. The fix being taken here is to recognize when the projects we are being handed are IVsIntellisenseProjects which means we can distinguish the projects that don't need an output path from ones that do. This ensures we don't end up with these projects having output paths at all, which probably wouldn't end well since they don't correspond to the actual code ultimately emitted to disk. We'll only ignore the project if it also has a duplicate IVsHierarchy, to avoid breaking project types (like database projects) that do create an IVsIntellisenseProject for some files, but it's not a secondary project but rather the only project.
-
由 Jason Malinowski 提交于
-