- 05 6月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 04 6月, 2015 11 次提交
-
-
由 David Poeschl 提交于
-
由 Manish Vasani 提交于
Fix ITypeSymbolExtensions.IsOrDerivedFromExceptionType to handle type parameters constrained on Exception type or its subtype. Fixes #3254
-
由 Tom Meschter 提交于
Fix a NullReferenceException when setting diagnostic severity. **Bug:** Fixes #3098. **Customer Scenario** 1. Customer adds the NuGet package for Microsoft.AnalyzerPowerPack, System.Runtime.Analyzers, or System.Runtime.Interop.Analyzers (really, any package containing FxCop rules implemented as Roslyn analyzers). 2. In the Solution Explorer, the customer expands the References | Analyzers | Microsoft.AnalyzerPowerPack.Common node. 3. User right-clicks on CA2229 and selects "Set Rule Set Severity" | Error. 4. The effective severity of the rule changes to Error. 5. User right-clicks again and this time selects "Default" for the severity, intending to reset it to its default value. 6. The severity is not adjusted, and instead the following dialog pops up: ![image](https://cloud.githubusercontent.com/assets/235241/7825354/dbe7155e-03c0-11e5-819b-5beac1ffd2ad.png) Note that VS does not crash, and after dismissing the dialog VS continues to function. **Fix Description** It is possible to have multiple `<Rule>` elements with the same ID in a rule set file, so long as they specify the same Action. This is likely to happen with former FxCop rules--you'll end up with one copy under the "Microsoft.Analyzers.ManagedCodeAnalysis" analyzer (from FxCop) and one under "Microsoft.AnalyzerPowerPack.CSharp" or similar (from a Roslyn-based analyzer). When the user selects one of these rules in Solution Explorer and sets the severity to "Default" we need to find each rule with the matching ID, and remove them all from the rule set file. However, we remove the rules while we're in the middle of the enumeration, tripping up the enumerator and leading to `NullReferenceException`s. The fix is to first flatten the enumeration of items to be removed to a list, and then remove them. The first commit in this pull request implements the fix, the next two reorganize the code and add unit tests. **Testing Done** I added unit tests around the code in question, include one that fails without the fix. I also ran through the scenario described above and validated that the rule set was updated as expected after I implemented the fix.
-
由 Tomáš Matoušek 提交于
Replace public fields with properties in compiler API
-
由 Jason Malinowski 提交于
Deal with solutions with circular project references in MSBuildWorkspace
-
由 Dustin Campbell 提交于
Code Model: When setting the name of a CodeElement, ensure that its members are updated
-
由 Andy Gocke 提交于
Port PR #3237 to stabilization -- Catch exceptions when creating a stream for signing
-
由 Ravi Chande 提交于
Handle "Color color" from VB completion
-
由 Matt Warren 提交于
Remove tail recursion and enable cancellation
-
由 AlekseyTs 提交于
Do not cut short binding of “return” statement even if expression has syntax errors.
-
由 AlekseyTs 提交于
Check current language version for “Global” keyword only if it starts namespace name in namespace declaration.
-
- 03 6月, 2015 12 次提交
-
-
由 David Poeschl 提交于
Update stabilization cibuild scripts
-
由 David Poeschl 提交于
The cibuild scripts had diverged between stabilization and master. This change brings stabilization back in sync with master and makes a small change to ensure passing invalid commandline arguments returns a proper error code.
-
由 Jason Malinowski 提交于
If we have a solution with circular references, leave one as a metadata reference to prevent deadlocks when trying to get compilations.
-
由 Manish Vasani 提交于
Fix ITypeSymbolExtensions.IsOrDerivedFromExceptionType to handle type parameters constrained on Exception type or its subtype Fixes https://github.com/dotnet/roslyn/issues/3254 User scenario: User writes code where they have explicit casts to a type parameter deriving from Exception type or its subtype. We will offer incorrect cast removal fixes to remove these explicit casts. Removing such casts will cause their code to not compile. Even worse, if they apply a FixAll occurrences code fix, then all such casts across their (document/project/solution) will be removed, causing tons of compile errors. Fix description: IsOrDerivedFromExceptionType was only checking for base types of the given type symbol to detect if the type is an Exception type. We also need to handle type parameters which are constrained by Exception or its subtypes. Testing: Added regression tests + existing tests.
-
由 Tom Meschter 提交于
Add unit tests to cover modifying rule set documents.
-
由 Tom Meschter 提交于
Extract the code to modify rule sets to a helper type.
-
由 AlekseyTs 提交于
Addresses DevDiv 1179899.
-
由 David Poeschl 提交于
Pass correct itemIDs to IVsSymbolicNavigationNotify
-
由 Tom Meschter 提交于
Fixes #3098. It is possible to have multiple `<Rule>` elements with the same ID in a rule set file, so long as they specify the same Action. This is likely to happen with former FxCop rules--you'll end up with one copy under the "Microsoft.Analyzers.ManagedCodeAnalysis" analyzer (from FxCop) and one under "Microsoft.AnalyzerPowerPack.CSharp" (from a Roslyn-based analyzer). When the user selects one of these rules in Solution Explorer and sets the severity to "Default" we need to find each rule with the matching ID, and remove them all from the rule set file. However, we remove the rules while we're in the middle of the enumeration, tripping up the enumerator and leading to `NullReferenceException`s. The fix is to first flatten the enumeration of items to be removed to a list, and then remove them.
-
由 Andrew Casey 提交于
Loosen check in CapturedVariableRewriter.RewriteParameter
-
由 Andrew Casey 提交于
When we added support for transparent identifiers, we loosened the existing check so that they wouldn't be flagged as erroneous. We should have gone further and indicated that all anonymous types (i.e. including user-declared ones) are okay. Because of the way its check is structured, VB is unaffected. Fixes #3231
-
由 Andy Gocke 提交于
This change is meant to address crashes like the ones in bug 1140649. The crashes seem to happen due to exceptions thrown while getting a temporary output stream to write the PE file to. I have been unable to reproduce the conditions for the crash themselves -- they only seem to happen on a Japanese language Windows with a Japanese language copy of Visual Studio. This fix addresses their symptom by wrapping the CreateInputStream call during signing with a try/catch and then surfacing the exception as a diagnostic for signing failure. We cannot currently add any more localized resources to stabilization, so this fix is meant to be as targeted as possible and can only deliver information through existing resource strings. (cherry picked from commit 801a10a5)
-
- 02 6月, 2015 16 次提交
-
-
由 Ravi Chande 提交于
Fixes #3086.
-
由 Dustin Campbell 提交于
-
由 AlekseyTs 提交于
Check current language version for “Global” keyword only if it starts namespace name in namespace declaration. Addresses DevDiv 1129404.
-
由 Dustin Campbell 提交于
Add unit tests for PR #3242 that correctly trigger the failure when the change is not present, but pass when it *is* present.
-
由 Manish Vasani 提交于
Add an analyzer to catch incorrect usage of CodeAction.Create API for fixers that support FixAllProvider
-
由 Tomas Matousek 提交于
-
由 Dustin Campbell 提交于
Code Model tracks nodes with a "node key" concept, which is effectively the full name of an element coupled with an ordinal. When the name of a CodeElement is updated, its node key must also be updated since the name of the underlying node has changed. However, we had failed to update the node keys of any members of that CodeElement, which means that they can no longer be located after their parent container's name changes. This is now fixed.
-
由 Manish Vasani 提交于
Handle non-source file diagnostics in the VB command line diagnostic formatter
-
由 Manish Vasani 提交于
User scenario: A CodeFixProvider that supports fix all occurrences code fix, gets FixAll support in IDE if it registers a single code action, but disappears as soon as fixer registers multiple code actions. Reason: A CodeFixProvider that intends to support fix all occurrences must classify the registered code actions into equivalence classes by assigning it an explicit, non-null equivalence key which is unique across all registered code actions by this fixer. This enables the FixAllProvider to fix all diagnostics in the required scope by applying code actions from this fixer that are in the equivalence class of the trigger code action. The analyzer added by this change catches violations of this requirement in the code actions registered by a CodeFixProvider that supports FixAllProvider. Fixes #2864
-
由 AlekseyTs 提交于
Ensure SemanticModel reports node as a default instance access rather than as a type reference, when the type reference is reclassified as such.
-
由 Manish Vasani 提交于
User scenario: User compiles a project with analyzers, and analyzer(s) generates a diagnostic with location in a non-source additional text file, but msbuild doesn't report such analyzer diagnostics and exits with code 1 with no output. Bug description: For analyzer diagnostics in additional file, VB command line compiler doesn’t output any file information or squiggles. However, it does include the file name and location in the output. This format doesn't match the Vbc MSBuild task parsing logic which expects the output to have either all of this information (file path, location, file content and squiggles) OR none of it for no-location diagnostic. This causes the Vbc task to ignore additional file diagnostics. Fix description: Fix the VB command line diagnostic formatter to always output diagnostics in either of the above 2 formats expected by MSBuild. For additional file diagnostics, the formatter now attempts to read the additional file stream and if it succeeds, formats it as a source diagnostic with location info and squiggles. Otherwise, it formats it as a no-location project diagnostic. Testing: Added regression test + existing tests. Also verified that the original issue reported on Roslyn.sln is also fixed by this change.
-
由 David Poeschl 提交于
Partial fix for internal TFS bug #1169405 We previously always passed Nil for all itemidCodeFile parameters in IVsSymbolicNavigationNotify to ensure the XAML language service heard our request (because their current implementation only processes request for Nil or 0-valued itemids.) This caused Go To Definition and Find All References to be slower than necessary in non-XAML cases and also resulted in unwanted behaviors on certain properties that are referenced in XAML. Our two options for fixing this were to either: 1. Update our implementation to send the correct item ids for heuristically "non-generated" files and send Nil for "generated" files (to match the Dev12 behavior) 2. Always send the actual item ids, even for "generated" files, and update the XAML language service to do a fast initial check of the corresponding document to see if they're interested in processing it. This changeset represents the Roslyn half of option 2. Any builds that contain this fix but do not contain the corresponding change to the XAML language service will see no Go To Definition navigation to .xaml files (e.g. when navigating from a reference to a named Button) and no .xaml file entries in Find All References. Unfortunately, this does not remove all heuristics from this algorithm, because Roslyn must still decide which itemid to pass in the case of a definition spanning multiple documents (e.g. the MainWindow class created in default WPF projects). We always prefer the "generated" documents to give external language services the best opportunity to participate.
-
由 David Poeschl 提交于
-
由 David Poeschl 提交于
If IVsHierarchy.ParseCanonicalName returns something other than S_OK, then use VSITEMID.Nil
-
由 Matt Warren 提交于
-
由 Andrew Casey 提交于
Clean up EE skipped tests
-