- 04 3月, 2015 6 次提交
-
-
由 Manish Vasani 提交于
Re-enable passing test TestFixAllInDocument_QualifyWithThis. Matt Warren fixed the underlying issue in SyntaxTree.GetChanges(SyntaxTree).
-
由 Paul Harrington 提交于
-
由 Stephen Toub 提交于
In a handful of places, Task.FromResult(true), Task.FromResult(false), and Task.FromResult(default(T)) were being used, even though equivalent cached tasks are available in SpecializedTasks. This commit just changes those ~20 call sites to use already cached tasks.
-
由 Brett Forsgren 提交于
-
由 Balaji Krishnan 提交于
Also added a smart, where, if we are in an expression bodied member context and if the right side of arrow clause contains a block, we generate local as if we're in a block context. This leads to an experience where we can keep the expression body syntax and also have introduce a local (since we have a block) without having to rewrite it to an equivalent full bodied member whose body is always a block.
-
由 David Poeschl 提交于
Fixes #540 "Stale rename entries in the lightbulb menu" Prior to this change, dismissed rename tracking sessions continued to provide codefixes which would silently fail when invoked, without completing the rename operation. With this change, we now do the following when rename tracking is manually dismissed: - Trigger the diagnostic service to reanalyze the document, thus removing the rename tracking diagnostic. - Stop providing a codefix when requested - Show a dialog if a cached codefix is invoked explaining that the rename was not performed. Here are the there user scenarios: 1. The user dismisses rename tracking - The lightbulb will continue to show in the margin, regardless of whether any codefix/refactoring is actually still available. 2. The user expands the lightbulb without it ever having been expanded before. - In this case, we are queried for fixes and will not return any, so either the lightbulb will disappear or it will contain other relevant codefixes/refactorings at that position, excluding rename. 3. The user expands the lightbulb after it was previously expanded. - Our fix was already cached, so we can only give a reasonable message when it is invoked. Once #885 is fixed, we can instead implement IDiagnosticUpdateSource and avoid forcing diagnostic reanalysis.
-
- 03 3月, 2015 4 次提交
-
-
由 Brett Forsgren 提交于
-
由 Balaji Krishnan 提交于
-
由 Balaji Krishnan 提交于
Bodied Members. This commit adds preliminary support to generate fields and a few tests for C#. This is a more straightforward scenario, than offering to generate locals, in which case we have to rewrite the expression bodied member to an equivalent normal one. Support for such scenarios and lots more test to follow in future commits.
-
由 Brett Forsgren 提交于
-
- 28 2月, 2015 4 次提交
-
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
-
由 Balaji Soundrarajan 提交于
Fixes #725: 'this' keyword should be available in the completion list, in the context of member expression body.
-
由 beep boop 提交于
Been almost a month since the code formatter was run so this change was a bit larger than would be expected for a normal (weekly) update. Diffs mostly around: - Whitespace changes - Missing copyright headers - Missing visibility modifiers
-
- 27 2月, 2015 9 次提交
-
-
由 Heejae Chang 提交于
all tests passing. now StateManager owns all state related operation.
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
-
由 Balaji Soundrarajan 提交于
Fix #872 : Indent appropriately on Enter inside InterpolatedVerbatimString If the Return is issued in the context of the InterpolatedString, the next line is placed at the column 0 If the Return is issued inside the Interpolated syntax of the InterpolatedVerbatimString then place the next line accordingly to the indentation rule
-
由 Ravi Chande 提交于
Completion on backspace uses the caret position to determine if it should trigger, which involves inspecting the subject buffer. It did not map the text view caret position onto the subject buffer position. This resulted in crashes in projection scenarios when the surface buffer was longer than the subject buffer.
-
由 Ravi Chande 提交于
Automatic brace completion of "(" parses as a cast, but the user might be trying to type a parenthesized expression.
-
由 Manish Vasani 提交于
1. Add declaration info for ArrowExpressionClauseSyntax: For properties and indexers, this node declares the getter method symbol whose IsImplicitlyDeclared flag is false and hence the analyzer symbol actions need to be invokedfor this getter. 2. Previously executable code block actions for nodes within ArrowExpressionClauseSyntax were executed with parenting property symbol as the owning symbol. This change fixes it to have the declared getter method symbol as the owner of executable block for ArrowExpressionClauseSyntax.
-
由 Brett Forsgren 提交于
-
由 Brett Forsgren 提交于
-
- 26 2月, 2015 2 次提交
-
-
由 Brett Forsgren 提交于
-
由 Brett Forsgren 提交于
-
- 25 2月, 2015 4 次提交
-
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
1) Don't crash command line builds when reporting analyzer diagnostics. Reporting analyzer diagnostics may involve invoking user code for LocalizableString message, which may throw while finding resources or for other unknown reasons. We catch exceptions from these callbacks and report a diagnostic with the inner exception message. I verified that this addressed the crash seen in #271 and #813 and we started seeing this new info diagnostic. 2) Workaround for #271: The underlying cause of the crash is that our assembly resolver/CLR is unable to fallback to the main assembly for resources and ends up looking for the satellite resource assembly. We had seen this crash quite a while back, but it went away and this seems to have come up again. Workaround, as applied back then, is to mark the analyzer assembly with NeutralResourcesLanguageAttribute. I verified that adding this attribute to our core analyzer assemblies caused the resource to be correctly found and we don't even see the exception diagnostic from (1) above, but instead the actual diagnostic reported by the analyzer.
-
由 Vladimir Reshetnikov 提交于
Fix #409: Add explicit StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase where it was intended, or replace single-char string literals with chars literals. Also, provide InvariantCulture in TryParse where it was intended.
-
由 Balaji Soundrarajan 提交于
Fixes #791: The code '\*' is parsed as MultiLine Comment even with the presence of the corresponding '*\' in some cases. Hence, OutLining Span creator should not assume that '*\' will always be present for Multiline Comment and handle the creation appropriately
-
- 24 2月, 2015 8 次提交
-
-
由 Manish Vasani 提交于
Fix for #565: Syntax node actions are not called for field declarations in compiler analyzer driver if the declaration defines multiple variables Simplify logic for execution of syntax node actions for field declarations: If there are multiple decls, execute syntax node actions for entire field decl (and its descendants) when processing symbol declared event for first field within it, and skip syntax node actions for rest of fields defined within that declaration. Current logic is unnecessarily complex in that it tries to execute syntax node actions for individual variable declarators when processing corresponding field symbol declared event, and executes the node actions for shared nodes (e.g. defining type syntax node) when processing first field symbol.
-
由 Brett Forsgren 提交于
-
由 Brett Forsgren 提交于
-
由 Brett Forsgren 提交于
move duplicate localized string to WorkspacesResources and remove all occurences of the hard-coded version
-
由 Brett Forsgren 提交于
-
由 Brett Forsgren 提交于
-
由 David Poeschl 提交于
Fixes #466 "Use a 'TriggerDiagnosticDescriptor' for the rename tracking diagnostic" Updates the RenameTrackingDiagnosticAnalyzer to use a TriggerDiagnosticDescriptor, which prevents the diagnostic title from appearing in the preview area of the lightbulb. We now pass the RenameFrom and RenameTo names as part of the Diagnostic's property bag and construct the localized codefix title based on these in the codefix itself.
-
由 Brett Forsgren 提交于
-
- 23 2月, 2015 3 次提交
-
-
由 Ravi Chande 提交于
VB does not support virtual events.
-
由 Dustin Campbell 提交于
In string interpolations, parentheses can't be removed if they surround some expression that includes a : or :: token. Othewise, a parsing ambuity will be introduced due to the : that delimits the format clause (i.e. $"{number:x4}"). Fixes Issue #724.
-
由 Brett Forsgren 提交于
-