- 28 4月, 2015 25 次提交
-
-
由 Balaji Soundrarajan 提交于
Serialize left out Shared Formatting Options
-
由 AlekseyTs 提交于
Adjust constraints check for reduced extension methods to avoid failures for type parameters that couldn't be inferred from the first argument.
-
由 Jonathon Marolf 提交于
Extra ?. for safety
-
由 Jonathon Marolf 提交于
-
由 Balaji Krishnan 提交于
Extract method in Expression bodied members. Fixes #528
-
由 Kevin Pilch-Bisson 提交于
Updated - More use of nameof() operator in ArgumentException and derived classes Switched from quoted argument names to nameof() operator, correcting a dozen or so in this manual process. RoslynLight.sln builds in VS2015 CTP6 and BuildAndTest.proj runs all tests without errors. Note I did not update cases like: new ArgumentException("symbol") because according to the signature, the first parameter holds message and second holds parameter name. Not sure how the team would like to change this. Mostly affects code generated from Syntax.xml.
-
由 AlekseyTs 提交于
Adjust constraints check for reduced extension methods to avoid failures for type parameters that couldn’t be inferred from the first argument. Fixes #2288.
-
由 Balaji Krishnan 提交于
#971 is now fixed, re-enable tests that were blocked on it.
-
由 Balaji Krishnan 提交于
Add support for extract method to work inside expression bodied members and unit tests.
-
由 bartkoelman 提交于
-
由 bartkoelman 提交于
-
由 bartkoelman 提交于
-
由 Balaji Soundrarajan 提交于
Fix #2218 : The Formatting Options UseTab, TabSize, IndentSize and IndentStyle were not getting persisted. This change fixes it. The integration tests will be added.
-
由 bartkoelman 提交于
-
由 Manish Vasani 提交于
Fix a race condition in BatchFixAllProvider's merge logic, in presence of merge conflicts. The current merge logic that merges code fixes from batch fixes ignores individual text changes that conflict with already merged batch fixes. This can be problematic if we have already merged a fix in the document in a later text span. We may end up adding text changes of kind Insert, but silently ignore text changes of kind Remove, returned by SyntaxTree.GetChanges(tree). This can cause the merged text document to be completely corrupt. Fix is to ignore all the text changes from a code fix (that is part of batch fixes) if any of its text change has a conflict. NOTE: DotNetAnalyzers/StyleCopAnalyzers#723 represents another case similar to #463, where SyntaxTree.GetChanges returns an add + remove text change with long spans, when the actual text change is just a single char replace. This causes completely independent code fixes to seem as conflicting to the batch fixer. I'll file a separate issue for this API bug. Fixes #320
-
由 Kevin Pilch-Bisson 提交于
When classifying xml nodes in VB, use FullSpan Since the editor calls us line by line, if we get called to classify a comment trivia on the line before an xml node, we would not do so as part of that line, because it doesn't overlap the Span. We would later do so, but not actually return the spans to the editor, since they didn't overlap the span requested. Fixes #2126.
-
由 Srivatsn Narayanan 提交于
Moving CA1003 and CA2002 to System.Runtime.Analyzers
-
由 Manish Vasani 提交于
Add skipped test for another repro case for #463
-
由 Srivatsn Narayanan 提交于
-
由 Manish Vasani 提交于
-
由 Andy Gocke 提交于
Closes #1700.
-
由 Srivatsn Narayanan 提交于
Cleaned up CA1821 (Remove empty finalizers) and fixed a bug in the fixer
-
由 Jonathon Marolf 提交于
Adding error triggers for the add-usings fixers Fixes #935 Fixes #562
-
由 Jonathon Marolf 提交于
-
由 Kevin Pilch-Bisson 提交于
Make C# snippet completion obey the "SendEnterThroughToEditor" option Use the standard logic to determine whether to send enter through to the editor, which requires using CSharpCompletionItems. Fixes internal bug #1140893.
-
- 27 4月, 2015 8 次提交
-
-
由 Kevin Pilch-Bisson 提交于
Include Project Name and FilePath in debugger display for ProjectInfo Fixes #2159
-
由 Wonseok Chae 提交于
[Localize] partially localize a part of strings like "finally clause" We use resource commenting "locked" to define what to localize. It fixes #2215.
-
由 Tom Meschter 提交于
Add new analyzer assembly loaders. Currently we expect that an analyzer's dependencies are located next to it in the file system, and we do not require that those dependencies be explicitly passed to the compiler. These requirements are changing. We will now allow analyzers and their dependencies to be located anywhere, and this requires that the full set of analyzers and dependencies be passed in so that we know where to find them. In order to load analyzers and dependencies under these new requirements, this commit introduces two new analyzer loaders: * The `SimpleAnalyzerAssemblyLoader` type loads assemblies from their current location with a simple `Assembly.LoadFrom`. This is used in situations where it is OK to lock the file on disk for the lifetime of the process (e.g., in csc/vbc/csi/vbi) and as the default in the workspaces layer. * The `ShadowCopyAnalyzerAssemblyLoader` first copies an assembly and its resource files to a temporary location, and then loads it from there. This keeps the original file unlocked, and is meant to be used by longer- running processes (VS, vbcscompiler.exe). Both implementations also hook the `AppDomain.AssemblyResolve` event in order to find and load items from their list of dependencies. **Work included in the current review:** 1. Defining a loader that loads in-place (`SimpleAnalyzerAssemblyLoader`). 2. Defining a loader that shadow-copies assemblies and loads them from the new location (`ShadowCopyAnalyzerAssemblyLoader`). 3. Plumbing the loaders through csc/vbc/vbcscompiler/workspaces/VS. 4. Removing the old `InMemoryAssemblyProvider` entirely and updating the code that previously depended on it for notification for when an assembly was loaded. 5. Making the new loaders internal in order to minimize our public surface area.
-
由 Manish Vasani 提交于
The current merge logic that merges code fixes from batch fixes ignores individual text changes that conflict with already merged batch fixes. This can be problematic if we have already merged a fix in the document in a later text span. We may end up adding text changes of kind Insert, but silently ignore text changes of kind Remove, returned by SyntaxTree.GetChanges(tree). This can cause the merged text document to be completely corrupt. Fix is to ignore all the text changes from a code fix (that is part of batch fixes) if any of its text change has a conflict. NOTE: https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues/723 represents another case similar to #463, where SyntaxTree.GetChanges returns an add + remove with long spans, when the actual text change is just a single char replace. This causes completely independent code fixes to seem as conflicting to the batch fixer. I'll file a separate issue for this API bug.
-
由 Jonathon Marolf 提交于
Adding additional errors for the Add Imports/Usings fixers to react to. Now, when we get an error on an extension method we offer to import the correct namespace. Fixes #935 Fixes #562
-
由 Srivatsn Narayanan 提交于
-
由 dpen2000 提交于
-
由 Pilchie 提交于
Since the editor calls us line by line, if we get called to classify a comment trivia on the line before an xml node, we would not do so as part of that line, because it doesn't overlap the Span. We would later do so, but not actually return the spans to the editor, since they didn't overlap the span requested. Fixes #2126.
-
- 26 4月, 2015 2 次提交
- 25 4月, 2015 5 次提交
-
-
由 Srivatsn Narayanan 提交于
Moving CA2002 (Do not lock objects with weak identities) to System.Runtime.Analyzers. This is a simple rename and has no significant code change.
-
由 Srivatsn Narayanan 提交于
The fixer removed the squiggled node and for VB that would be a MethodStatementSyntax instead of a MethodBlockSyntax and the RemoveNode call fails. Fixing it by simply calling SyntaxGenerator.GetDeclartation before removing and that does thte right thing. Fixes #2257
-
由 Shyam N 提交于
Fixes #1899 Consider the following case where M1 and M2 are non-existant methods - this.M1(System.Exception.M2()); The code fix provider for generate method was offering two fixes to generate the method M1 above. Here's why. The fix provider gets called once each for the two diagnostics on the above line - the first with span corresponding to M1 and the second with span corresponding to M2. For the first span, the fix provider correctly constructs a fix to generate M1. For the second span the fix provider correctly realizes that it can't construct a fix to generate M2 since System.Exception is a type from metadata and not source. However, looks like fix provider has fallback code to walk up the tree and see if there are other methods that it can construct in such cases. It ends up finding the InvocationExpression for M1 up the tree and therfore ends up returning another fix for generating M1. I didn't want to change this fall back logic since it appears to be shared across multiple GFU fix providers and I didn't want to break other legit cases where this may be required for generate method. Instead I am fixing this by introducing equivalence key for the corresponding CodeAction to ensure that the duplicate fixes will get filtered out when the light bulb presents the list of fixes in its UI. (This is identical to equivalence keys that we have in place for other GFU fixes such as Generate Type etc.). Note that we need the equivalence key for generate method anyways to avoid duplicate fixes in other unrelated cases such as following where M is a non-existant method - var x = this; var y = this; string.Format("{0}:{1}", x.M(), y.M()) Also, note that in some cases where we used to offer multiple valid fixes to generate methods with the same name but different signatures before, we will now only display one fix at a time. But this is fine since user can always fix first issue then invoke light bulb again to fix 2nd issue. Example of a case where there are 2 methods with same name but different signature - this.M(this.M());
-
由 Brett Forsgren 提交于
re-filter signature help providers if the file's content type has changed
-
由 Wonseok Chae 提交于
We use resource commenting "locked" to define what to localize.
-