“5f376274be94397fd9644601923ff88c56292a02”上不存在“source/git@gitcode.net:taosdata/tdengine.git”
- 11 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 31 8月, 2016 1 次提交
-
-
由 David Poeschl 提交于
Fixes #8297 by checking to see if the cascaded constructor (or similar) is a keyword. This is the same check that's performed when deciding whether to allow rename to be invoked on a constructor (or similar). This should only impact VB
-
- 27 4月, 2016 1 次提交
-
-
由 Neal Gafter 提交于
-
- 17 3月, 2016 1 次提交
-
-
由 Jinu Joseph 提交于
-
- 11 3月, 2016 1 次提交
-
-
由 AlekseyTs 提交于
-
- 10 3月, 2016 1 次提交
-
-
由 David Poeschl 提交于
Fixes #8139 We were previously asserting that renaming a private member meant that the rename operation would occur entirely in that member's declaring project, but rename affect other projects if the private member is an explicit implementation of a public interface member.
-
- 08 3月, 2016 1 次提交
-
-
由 Jason Malinowski 提交于
No functional change here.
-
- 05 3月, 2016 1 次提交
-
-
由 Jason Malinowski 提交于
This is all the tests that we've seen fail as a part of investigating issue #9308.
-
- 03 3月, 2016 3 次提交
-
-
由 Neal Gafter 提交于
-
由 Neal Gafter 提交于
Closes #9079 #9080
-
由 Jared Parsons 提交于
-
- 26 1月, 2016 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Manually inspected the WorkItem values and added the appropriate URL.
-
- 19 12月, 2015 1 次提交
-
-
由 Jason Malinowski 提交于
-
- 17 12月, 2015 1 次提交
-
-
由 Jason Malinowski 提交于
These tests were all using WpfFact, but not actually doing anything that required either WPF or an STA thread. We plan to enable parallelization of Facts (but not WpfFacts), and this ensures we can parallelize as many tests as possible.
-
- 16 10月, 2015 1 次提交
-
-
由 Paul Harrington 提交于
-
- 10 10月, 2015 1 次提交
-
-
由 Tanner Gooding 提交于
-
- 01 7月, 2015 1 次提交
-
-
由 Charles Stoner 提交于
-
- 19 5月, 2015 1 次提交
-
-
由 David Poeschl 提交于
Fixes #1195 "Renaming a member to a name used within a nameof is a conflict" When a nameof expression is involved in a rename, conflicts are only introduced if the nameof previously referenced a non-empty set of symbols and the post-rename set of referenced symbols contains none of the previously referenced symbols. This allows overloads to join or exit the set of references without conflicts, but a conflict is still offered if the nameof switches from referencing a method to referencing a local (or similar).
-
- 18 5月, 2015 1 次提交
-
-
由 David Poeschl 提交于
Fixes #1729 The C# implementation of IRenameRewriterLanguageService.LocalVariableConflict was returning conflicts any time a related invocation expression bound to a local/parameter, but this condition is not indicative of a conflict when the local/parameter is of a delegate type. This change prevents reporting this particular kind of conflict on references to locals & parameters of a delegate type.
-
- 17 3月, 2015 1 次提交
-
-
由 David Poeschl 提交于
Fixes #1193 During expansion, directly accessed members need to be qualified with "this." or "TypeName.". Prior to this change, we always qualified instance members with "this." and static members with "TypeName.", but this technique fails in nameof contexts where an instance member can be referenced from a static method, resulting in an improper "this." qualification. We can only legally use "this." when both the member being accessed and the context from which we are accessing it are non-static. However, this change updates the expanders to always use "TypeName." qualification in nameof contexts regardless of the staticness of either member because it is always legal and feels more natural in nameof expressions (where no actual value is being accessed).
-
- 12 3月, 2015 2 次提交
-
-
由 Ravi Chande 提交于
The expander can operate on a specific set of known nodes, so when rename finds a conflict in a particular node, it uses the span of a parent that the expander knows how to handle. For normal ArgumentSyntaxes, this is covered by being within a StatementSyntax. However, nameof within an attribute constructor isn't in a statement, so rename needs to expand to the span of the attribute.
-
由 David Poeschl 提交于
This change adds support for renaming methods that are referenced in nameof expressions during Inline Rename, Rename Tracking, and RenameSymbolAsync. For all of these features, there are three primary cases: - Rename invoked from a method declaration with no overloads: Any nameof expressions that reference the method are unambiguous and are therefore updated to the new name. - Rename invoked from a method declaration with overloads: In this case, any references in nameof expressions are renamed only if the RenameOverloads option is set to true (e.g. when the user checks the "Rename overloads" checkbox in Inline Rename). - Rename invoked from a reference in a nameof expression: We always rename all overloads by automatically setting the RenameOverloads option to true and disabling Inline Rename's "Rename overloads" checkbox.
-
- 29 1月, 2015 1 次提交
-
-
由 beep boop 提交于
-