- 09 6月, 2015 6 次提交
-
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
- 06 6月, 2015 3 次提交
-
-
由 Tanner Gooding 提交于
[Automated] Merge 'stabilization' and 'master' into 'future'
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
- 05 6月, 2015 19 次提交
-
-
由 Tanner Gooding 提交于
[Automated] Merge 'stabilization' and 'master' into 'future'
-
由 Tanner Gooding 提交于
-
由 Jared Parsons 提交于
Extend Linux CI Support
-
由 Tanner Gooding 提交于
[Automated] Merge 'stabilization' into 'master'
-
由 Evan Hauck 提交于
Refactor Compilation to pull features from ParseOptions
-
由 Tanner Gooding 提交于
-
由 Evan Hauck 提交于
-
由 Jonathon Marolf 提交于
Correctly detect option strict on/off when determining if cast is red…
-
由 Dustin Campbell 提交于
Code Model: Fix issue with parented code model objects corrupting their parents
-
由 Dustin Campbell 提交于
Don't pretty-list away line continuation characters in VB 9 or earlier
-
由 Charles Stoner 提交于
Changes InteractiveWindow.vsct to use image monikers Port e7dd6093 to stabilization branch See #3165
-
由 Manish Vasani 提交于
Gracefully bail out on extension method rewrite within conditional access expressions Fixes #2593 User scenario: User types a conditional access expression with a subsequent extension method invocation. For example, "a?.Method().ExtensionMethod()". Attempting to perform any simplification (cast simplification, simplify name) or refactorings (inline temporary) causes a exceptions in the simplification engine and all these IDE services are disabled for the project. Issue description: We are not handling conditional access expressions, and hence member access or invocations with null "left of dot" nodes, in our expander. Additionally, performing extension method expansion (to a static method invocation with receiver replaced as the first argument to invocation) is non-trivial. Fix description: This change makes a defensive fix by: 1. Guarding against null reference exceptions. 2. Bailing out on extension method rewrite within conditional access expressions. Approved 6/4 by ML Shiproom.
-
由 AlekseyTs 提交于
Include ContentType into assembly qualified type name emitted for an attribute argument.
-
由 Tomáš Matoušek 提交于
Report rude edit when a partially executed active statement is edited
-
由 Evan Hauck 提交于
Fix System.String[] sometimes printing in unit tests
-
由 Steve Dower 提交于
Removes old image resource Reorders sections in InteractiveWindow.vsct to match the schema
-
由 Evan Hauck 提交于
-
由 Charles Stoner 提交于
Include accessible private members from outer types in Intellisense [stabilization branch] Port f9bd1d1f to stabilization branch
-
由 Tomas Matousek 提交于
-
- 04 6月, 2015 12 次提交
-
-
由 Charles Stoner 提交于
Conflicts: src/EditorFeatures/VisualBasicTest/Completion/CompletionProviders/SymbolCompletionProviderTests.vb
-
由 Heejae Chang 提交于
make formatting performance better ... this performance improvement is particularly for devdiv bug # 1089540 this makes the file in the bug to be formatted in several seconds compared to several minutes on my machine. there were several issues. each one fixed by #1, use concurrency on gathering operations. #2, don't use too much time to split work to chunks if that requires more work than actually formatting. #3, don't blindly set beginning of a file as inseparable start point for certain formatting options. ... but these don't actually address the most impactful root cause of this perf issues. which is perf issue of GetPrevious/GetNextToken API in compiler. (#3244) formatter internally uses GetDescendantTokens to get all tokens at once and cache them which takes less than 1 second for the entire file (2M bytes size) in the bug. and use the cache internally. but certain part of formatter (Rule Provider) can't use that internal cache, so it has to use the GetPrevious/GetNextToken to move around tokens, which in this particular bug, takes more than 40 seconds on my machine. and that is not even for entire file. (less than 1/12 of tokens) I opened a bug to compiler team, hopely so that we can get better perf on those APIs. in this PR, I mitigated the issue either by making more things to run concurrently or by changing logic which requires those APIs.
-
由 Jonathon Marolf 提交于
Responding to peer review feedback. Updated to never consider user defined narrowing conversions unnecessary.
-
由 Jonathon Marolf 提交于
Fixes #3161 and Fixes #3163 User Scenario: User has code with narrowing conversion with an explicit cast. We will offer to remove the cast even though this will cause the code to not compile. Fix Description: We previously never consulted optionstrict to determine if a user-defined narrowing cast was necessary. The fix in CastAnalyzer.vb will check if the conversion is narrowing, if option strict is on, or if we generate a warning on implicit narrowing conversions. We also offer to add a cast if an implicit conversion warning is given. Testing: Added regression tests + existing tests
-
由 AlekseyTs 提交于
Addresses DevDiv 1169511.
-
由 Charles Stoner 提交于
Changes InteractiveWindow.vsct to use image monikers Removes old image resource Reorders sections in InteractiveWindow.vsct to match the schema
-
由 Dustin Campbell 提交于
**Customer scenario**: VB customer has legacy project targeting an earlier version of the language. If they use Visual Studio 2015, we shouldn't remove their line continuation characters and break their program. The scenario this fix directly solves was filed on Microsoft Connect [here](https://connect.microsoft.com/VisualStudio/feedback/details/1035813/connect-vb-14-compiler-removes-line-continuations-even-when-web-config-specifies-vb-8-as-compiler). Essentially, this was filed by a customer who has a VB Web Site which specifically targets Visual Basic 8.0 for legacy reasons and can't use Visual Studio 2015 with the project. **Description of fix**: Don't run the Remove Unnecessary Imports code cleaner if the LanguageVersion is VB 9 or earlier. This addresses the customer-reported scenario because the VB Web Site project system will set the language version to VB 9 if the target framework is less than 4.0. **Testing done**: Unit tests added. Manually verified customer scenario.
-
由 Matt Warren 提交于
Enable xaml project test
-
由 Dustin Campbell 提交于
This is a fairly involved issue that can manifest in a number of ways. Currently, the only known scenario where this is exposed within VS is the "Convert to Web Application" command but there are certainly others and customers using Code Model could easily run into it. The scenario is essentially this: * In Code Model, grab and hold a reference to a code model object for some container element. * Access a certain type of child element parented by that container. In particular, a property accessor, an event accessor, an attribute, an attribute argument, a VB Inherits statement, a VB Implements statement, or using directive/Imports statement. * Try to access a property on the container reference in step 1. * Exception gets thrown! Understanding why this happens will require understanding a few of the system concepts underlying Code Model. First, Code Model elements tend to have long lifetimes that live through file edits and even renames. For example, one could grab a reference to an ```EnvDTE.CodeClass``` and hold onto it. As the user makes edits to the file containing that class the class element should continute to be valid (until the user makes an edit that breaks it). Since their lifetimes can be potentially long, Code Model elements hold onto "node keys" rather than the SyntaxTree nodes, which they use to get back to their underlying node in the source file. Node keys have a very simple format. Essentially, they are the "name" of the node (qualified syntactically) along with an ordinal which allows there to be multiple nodes with the same name. Consider the following code: ```C# namespace N { partial class C { void M() { } } partial class C { } } ``` In the code above, there are four potential Code Model elements with the following node keys: * N, 1 * N.C, 1 * N.C.M, 1 * N.C, 2 Second, some Code Model elements don't actually have node keys. These are objects that are parented by other code model objects. For example, parameters are parented within a method or propery, property accessors are parented within a property, etc. These "keyless" objects can be a bit tricky because they need to hold a reference to their parent object. Third, each FileCodeModel maintains a cache of Code Model elements using their node keys. Whenever a Code Model element is going to be created for a particular node key, the FileCodeModel first checks to see an element already exists. If so, it returns the cached element instead. With that background, here's what's happening: In several cases, creating a parented keyless Code Model element was skipping the lookup in the FileCodeModel's cache when creating it's parent. So, if an element represent the parent already existed in the cache, a second Code Model element would be created for the same node. This gets ugly because the process creating a Code Model element causes it to be added to the FileCodeModel's cache. So, there is an attempt to add the newly created Code Model element when there's already one present in the cache with the same node key. Ideally, this situation would have thrown an exception. However, when there's a collision, there's a code path in the FileCodeModel's cache that tries to find a free slot in the cache by changing the original of the element's node key. This code is super-suspicious and is, quite honestly, probably wrong. However, removing it is a risky at this point. So, I'll look at cleaning this up in the master branch. For now, I've audited all of the places where a parented keyless Code Model element constructs its parent and ensures that it goes through the FileCodeModel's lookup.
-
由 David Poeschl 提交于
-
由 David Poeschl 提交于
-
由 Matt Warren 提交于
-