- 28 10月, 2015 6 次提交
-
-
由 Kevin Pilch-Bisson 提交于
-
由 Kevin Pilch-Bisson 提交于
-
由 Kevin Pilch-Bisson 提交于
-
由 Kevin Pilch-Bisson 提交于
Conflicts: src/EditorFeatures/Core/EditorFeatures.csproj
-
由 Dustin Campbell 提交于
Fix VB incorrectly reported redundant casts in compound assignment statements
-
由 Dustin Campbell 提交于
Consider the following code: ```VB Dim b As Byte b += CByte(1) ``` The `CByte` cast can be removed if the Option Strict is Off. However, if Option Strict is On, the compiler produces an error ("Option Strict On disallows implicit conversions from 'Integer' to 'Byte'"). The issue here is that compound statements are not considered by unnecessary cast detection. Unfortunately, supporting is not as straight forward as I'd hoped for a couple of reasons: 1. There is no compiler API to get the built-in operator used by a VB assignment statement. If there were, this would be a straightforward fix since removing the cast results in the compiler choosing `System.Int32.op_Add(Int32, Int32)` rather than `System.Byte.op_Add(Byte, Byte)`. 2. There is a hidden narrowing-numeric conversion of a constant value in the following code: ```VB b += 1 ``` Using the compiler API to classify conversion from the expression `1` to the type of `b` results in a widening-numeric conversion, which is misleading since the type of `1` is `System.Int32` and the type of `b` is `System.Byte`. Fixing the problem requires two changes: 1. Actually support assignment statements in the speculative analyzer and check to see if replacment would break the compound assignment. 2. Add a special case in the VB speculative analyzer in the case that Option Strict is not Off and the expression has a constant value. In that case, we use a different compiler API to classify *the type of the expression* `1` to the type of `b`, rather than classifying *the expression* `1` to the type of `b`.
-
- 27 10月, 2015 26 次提交
-
-
由 Dustin Campbell 提交于
Properly handle VB WithEvents fields in metadata code model elements
-
由 Kevin Pilch-Bisson 提交于
Remove equivalenceKey from CodeAction.Create overload
-
由 Jared Parsons 提交于
Actually delete PumpingWait
-
由 Paul Harrington 提交于
Log low VM telemetry at most once per session
-
由 Jonathon Marolf 提交于
Fix VB Spellchecker Crash Fixes #6338
-
由 Jared Parsons 提交于
Now that the internal dependencies have been removed we can delete the PumpingWait methods.
-
由 Tomáš Matoušek 提交于
Support for ISymUnmanagedWriter7 deterministic PDB ID setting
-
由 Kevin Pilch-Bisson 提交于
-
由 Tomáš Matoušek 提交于
Avoid depencency on the exact order of AssemblyRefs in tests
-
由 Heejae Chang 提交于
Add logging to find all reference command handler
-
由 Jonathon Marolf 提交于
-
由 Jonathon Marolf 提交于
-
由 Kevin Pilch-Bisson 提交于
Automatically calculate equivalence keys from nested actions. Fixes #5975.
-
由 Tomas Matousek 提交于
-
由 Paul Harrington 提交于
Disable BackgroundCompiler on low VM
-
由 Heejae Chang 提交于
-
由 Kevin Halverson 提交于
[AskMode] Rename MS.CA.Scripting.CSharp to MS.CA.CSharp.Scripting...
-
由 Dustin Campbell 提交于
-
由 Kevin Halverson 提交于
[AskMode] Allow return statements in scripts...
-
由 Manish Vasani 提交于
Fix VSIX based analyzers installed in the extensions hive Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work. Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path. Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers. Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change. Fixes #6285
-
由 Kevin Halverson 提交于
...and update namespaces contained therein accordingly.
-
由 Kevin Halverson 提交于
-
由 Dustin Campbell 提交于
-
由 Dustin Campbell 提交于
-
由 Dustin Campbell 提交于
-
由 Dustin Campbell 提交于
* Remove lots of duplicated code * Add support for testing external code elements
-
- 25 10月, 2015 5 次提交
-
-
由 Jared Parsons 提交于
Remove PumpingWait
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
This removes PumpingWait from our test infrastructure and replaces it with proper await calls on the Task(s) in question.
-
由 Manish Vasani 提交于
Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work. Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path. Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers. Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change. Fixes #6285
-
- 24 10月, 2015 3 次提交
-
-
由 Neal Gafter 提交于
Add a PE file section for determinism
-
由 Neal Gafter 提交于
-
由 Jason Malinowski 提交于
Fixes for Building with Update 1
-