- 03 6月, 2015 1 次提交
-
-
由 Jason Malinowski 提交于
If we have a solution with circular references, leave one as a metadata reference to prevent deadlocks when trying to get compilations.
-
- 02 6月, 2015 2 次提交
-
-
由 Heejae Chang 提交于
fixed a race where build only errors are not cleared correctly
-
由 Ravi Chande 提交于
Rename dashboard navigation tweaks
-
- 01 6月, 2015 3 次提交
-
-
由 Manish Vasani 提交于
Add an analyzer that detects incorrect action registrations for stateful analyzers. Fixes #2949
-
由 Manish Vasani 提交于
Fixes #2949 User scenario: User writes an analyzer that either defines a CompilationStartAction or CodeBlockStartAction to perform stateful analysis on the compilation/code block. An analyzer start action enables performing stateful analysis over a given code unit, such as a code block, compilation, etc. Careful design is necessary to achieve efficient analyzer execution without memory leaks. This analyzer provides the following guidelines for writing such analyzers: 1. Define a new scope for the registered start action, possibly with a private nested type for analyzing each code unit. 2. If required, define and initialize state in the start action. 3. Register at least one non-end action that refers to this state in the start action. If no such action is necessary, consider replacing the start action with a non-start action. For example, a CodeBlockStartAction with no registered actions or only a registered CodeBlockEndAction should be replaced with a CodeBlockAction. 4. If required, register an end action to report diagnostics based on the final state. Fix description: We already have an analyzer flagging RegisterXXXAction invocations for other incorrect usages. This change adds 2 more rules to this analyzer to flag: 1. Start analysis context objects with only a registered end action. 2. Start analysis context objects with no registered actions. Testing: Added unit tests for this analyzer + manual testing. Verified existing tests pass.
-
由 Heejae Chang 提交于
changed bing search to use bing dev search
-
- 30 5月, 2015 18 次提交
-
-
由 Heejae Chang 提交于
fixed explicit cache bug in solution crawler
-
由 David Poeschl 提交于
Force Microsoft.Build.Tasks.CodeAnalysis into the VSIX
-
由 Jason Malinowski 提交于
When we build VisualStudioSetup.csproj, we include a bunch of assemblies from other projects into the VSIX. This is done through ProjectReferences to the other projects that produce each binary. It turns out this worked via some more magic than we expected: when we had a ProjectReference, we typically had the following metadata: <ProjectReference Include="..\..\Compilers\Core\Portable\CodeAnalysis.csproj"> <Project>{1EE8CAD3-55F9-4D91-96B2-084641DA9A6C}</Project> <Name>CodeAnalysis</Name> <IncludeOutputGroupsInVSIX>BuiltProjectOutputGroup</IncludeOutputGroupsInVSIX> </ProjectReference> When the VSIX targets run, they would collect all the files that need to be put into the VSIX. When it would encounter this ProjectReference, it would actually try to include the output twice. One copy (call it Copy A) would come from the Binaries folder simply by virtue that the binary was a reference from the VisualStudioSetup project and must be copied local. The other copy (Copy B) was coming from the obj directory, because the VSIX targets see us specifying the BuiltProject- OutputGroup and that output group's items point to obj. (There is metadata that points to the Binaries folder but that is getting ignored by the VSIX targets.) The VSIX packaging task would realize we were adding two copies of a file, it'd arbitrarily pick the first one, which happened to be the one in the Binaries folder. This magic blows up in one very special case. If the project's binary happens to be also found in the GAC, the default behavior of MSBuild is to no longer count that binary as CopyLocal. Thus, when the VSIX tried to include a binary that was in the GAC (in this case, Microsoft.Build.Tasks.CodeAnalysis.dll), it'd decide it didn't need to copy it local at all. Thus Copy A in the earlier description didn't exist, and so the VSIX packager would fall back to using Copy B, the copy of the assembly from the obj folder. When we're doing a signed build, Copy A and Copy B are actually different -- one is signed, one isn't, and so a lack of Copy A being given to the VSIX packager meant that we'd end up including unsigned assemblies in our (supposedly) fully signed VSIX. The "fun" part is during non-signed builds Copy A is included, since the locally-built binary (with version 42.42.42.42) isn't in the GAC. Thus if you try to reproduce the strange MSBuild behavior on a regular build you don't see it and you don't understand why. There are two quick fixes: 1. Un-GAC Microsoft.Build.Tasks.CodeAnalysis on any machines that need to do a proper signed build. 2. Force the DLL to be copied local. We take this approach since it's best to not be subject to the whims of the GAC if we can be. Long term, we probably should fix the VSIX targets to never look in the obj folder. They found the obj folder by looking at the items from the BuiltProjectOutputGroup, but didn't look at the appropriate metadata that would have let it realize it should really copy from Binaries. This Copy A vs. Copy B fight happens with any VSIX project, and it'd be best to avoid that.
-
由 AlekseyTs 提交于
Ensure PeNamedTypeSymbol.GetFieldsToEmit returns backing fields for events.
-
由 Matt Warren 提交于
Add metadata cache to default metadata service
-
由 Matt Warren 提交于
Still enable smart indent when auto-format on close brace is off
-
由 Ravi Chande 提交于
* Dashboard is no longer focused when starting inline rename * F2 outside a rename field commits the current session and starts a new one * F2 within a rename field focuses the dashboard
-
由 Dustin Campbell 提交于
Make CodeModel.CodeTypeFromFullName rational when returning types that appear in generated code files
-
由 Dustin Campbell 提交于
Ensure that FormattableString is preferred by Introduce Explaining Variable and Extract Method
-
由 Manish Vasani 提交于
Prevent duplicate invocations of per-compilation analyzer actions for a given symbol/syntax node in IDE. User scenario: An analyzer author writes a compilation end analyzer, which registers symbol and/or syntax node actions to maintain some state about them, and a compilation end action to report diagnostics based on the final sate. When running in the IDE, the analyzer will get duplicate callbacks to the symbol/syntax node actions for the same symbol/node in the compilation: once while computing active document diagnostics and once while computing project diagnostics. This can cause one of the following issues: 1. Crash the analyzer if it is using some map keyed on the callback symbol/node, and doesn't handle duplicate callbacks. 2. Corrupt the analyzer state by recording the state twice for a single symbol/node. 3. Possibly cause the analyzer to enter a race or deadlock. Fix Description: Fix is to ensure that when computing the compilation end diagnostics for such stateful analyzers, we use a new instance of the analyzer. All the compilation wide actions are then invoked on this new instance of the analyzer, avoiding duplicate callbacks into the same instance. Fixes #248 Testing: Added a regression test + existing tests. Approved 5/29 by ML Shiproom.
-
由 Kevin Halverson 提交于
Improve performance of IVsLanguageDebugInfo.GetNameOfLocation...
-
由 Kevin Halverson 提交于
Previously, we would fetch a SemanticModel and build containing Symbols for each breakpoint location. This could be very expensive in a large solution. However, for the purposes of providing parity with the old implementation, it is adequate to just inspect Syntax. (fixes #1977)
-
由 Manish Vasani 提交于
Do not localize diagnostic severity in the diagnostic formatter Fixes internal bug 1093063: 'csc2.exe'/ 'vbc2.exe' will ICE (exit with Code 1) when trying to report errors on localized installs User scenario: Create a default VB/C# project on a localized OS, introduce some errors/warnings and build the project from the command line through msbuild. Expected: Compiler diagnostics show up in the build output. Actual: No diagnostics are displayed, and msbuild exits with code 1. Fix Description: MSBuild tasks have a specific parsing logic to look for non-localized diagnostic severity strings such as "error" and "warning" in the compiler output to detect errors and warnings. Our diagnostic formatter was localizing these severity strings, causing the msbuild parsing to fail on localized OS. Fix is to match the Dev12 compiler behavior by not localizing the severity strings. Testing: Added regression tests + existing tests
-
由 Manish Vasani 提交于
Fixes internal bug 1093063: 'csc2.exe'/ 'vbc2.exe' will ICE (exit with Code 1) when trying to report errors on localized installs User scenario: Create a default VB/C# project on a localized OS, introduce some errors/warnings and build the project from the command line through msbuild. Expected: Compiler diagnostics show up in the build output. Actual: No diagnostics are displayed, and msbuild exits with code 1. Fix: MSBuild tasks have a specific parsing logic to look for non-localized diagnostic severity strings such as "error" and "warning" in the compiler output to detect errors and warnings. Our diagnostic formatter was localizing these severity strings, causing the msbuild parsing to fail on localized OS. Fix is to match the Dev12 compiler behavior by not localizing the severity strings. Testing: Added regression tests + existing tests.
-
由 AlekseyTs 提交于
Emit DebuggerStepThroughAttribute on async kick off method in order to improve stepping behavior during debugging.
-
由 Matt Warren 提交于
-
由 Dustin Campbell 提交于
CodeModel.CodeTypeFromFullName should prefer locations within source files that are not generated (using the same heuristic we use within the Generate Type dialog to determine whether a source file is "generated"). However, if the locations are *all* within generated sources, just return the first one. Scenario: this addresses a scenario where CodeModel.CodeTypeFromFullName is used to determine the right place to modify user code. In the case of XAML apps, there are several generated files that shouldn't be modified (i.e. .g.i.cs .g.cs, etc.). Previously, CodeTypeFromFullName might return one of these files as a location, breaking whatever feature was trying to modify the user's code. Unit tests have been added for this scenario in C# and VB that test a handful of permutations of generated and non-generated code with partial classes. Additionally, the Code Model unit testing infrastructure has been updated to support TestWorkspaces with multiple documents.
-
由 AlekseyTs 提交于
-
- 29 5月, 2015 16 次提交
-
-
由 Brett Forsgren 提交于
don't try to create an outlining span if valid start/end tokens can't be found
-
由 AlekseyTs 提交于
This fixes some Edit and Continue failures (DevDiv 1175704).
-
由 Dustin Campbell 提交于
-
由 Brett Forsgren 提交于
-
由 Matt Warren 提交于
-
由 Matt Warren 提交于
-
由 Heejae Chang 提交于
use different event to fresh build error list
-
由 Dustin Campbell 提交于
When extracting an interpolated string that is target-typed to FormattableString, the resulting declaration should use FormattableString as the type rather than string. Otherwise, the result is uncompilable code.
-
由 Brett Forsgren 提交于
prevent duplicate signature help items from surfacing to the UI
-
由 Heejae Chang 提交于
-
由 Jared Parsons 提交于
Don't restart on failed connection sequence
-
由 Matt Warren 提交于
-
由 David Poeschl 提交于
Port: Handle rename decl conflicts when decl file contains no refs
-
由 AlekseyTs 提交于
Emit DebuggerStepThroughAttribute on async kick off method in order to improve stepping behavior during debugging. Addresses DevDiv 1173179.
-
由 Andrew Casey 提交于
Handle out parameters in cross-language scenarios
-
由 Andrew Casey 提交于
Ignore the difference between ref and out in ```SymbolKey``` and ```SymbolEquivalenceComparer``` since two overloads cannot differ by only RefKind. This prevents VB FAR and GTD from being too discerning and missing matching references. Caveat: Switching between ```ref``` and ```out``` is still a rude edit, so EnC sets a switch to force consideration of the difference. Fixes #599.
-