- 23 5月, 2015 20 次提交
-
-
由 Tanner Gooding 提交于
This reverts commit e16d38bc.
-
由 Andrew Casey 提交于
Improve handling of My.InternalXmlHelper
-
由 Brett Forsgren 提交于
NavigateTo shouldn't consider generated files.
-
由 AlekseyTs 提交于
Do not run through following phases in Rewriter.LowerBodyOrInitializer once errors are encountered.
-
由 AlekseyTs 提交于
Import parameter's default constant value from metadata even if parameter is not optional.
-
由 Tomáš Matoušek 提交于
Make MetadataReference.CreateFromAssembly obsolete
-
由 Matt Warren 提交于
Dont auto-format some keys when smart indent is off
-
由 Andrew Casey 提交于
...as in Dev12.
-
由 Tomáš Matoušek 提交于
Harden access to MetadataReader
-
由 VSadov 提交于
Skip over partial methods with no implementation when emitting extra …
-
由 Tomáš Matoušek 提交于
C# EnC: handle addition of indexer
-
由 Brett Forsgren 提交于
Also add a check that the span returned by `ISyntaxFactsService.TryGetDeclaredSymbolInfo()` in SyntaxTreeInfo is valid.
-
由 Andrew Casey 提交于
Two things were preventing the EE from finding the type, which is needed for XML literal operations in VB: 1. It is marked internal and the accessibility check happened in AssemblySymbol, rather than the binder, so it was not hijacked. 2. It is marked with EmbeddedAttribute and is not from the SourceModule of the compilation (it's from the module of the current frame). We can resolve both of these problems by doing the lookups as though we were in the module containing the current frame. This required two changes: 1. Remove InternalXmlHelper from WellKnownTypes and give it its own code path. Explicitly pass the appropriate module symbol to the new helper. 2. In Binder.CheckViability, look for a containing module before falling back on the SourceModule of the compilation. By preserving the accessibility checks during type lookup (but doing them from the perspective of a different assembly), we retain the compiler's protection against pulling in a copy from each VB reference (i.e. ambiguity). The main caveat is that My.InternalXmlHelper will not be found if it was not embedded in the module containing the current frame - even if it is unambiguously available in a referenced assembly. Breaking change: unlike dev12, roslyn will only find My.InternalXmlHelper in the source module. Fixes #964
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
由 VSadov 提交于
-
由 dotnet bot 提交于
-
由 Matt Warren 提交于
Fix format rule for dot expression after label
-
由 Charles Stoner 提交于
Treat .csx/.vbx as regular source files from command-line compilers; change *ParseOptions.WithKind(SourceCodeKind) to internal; and throw NotSupportedException from CSharpParseOptions and VisualBasicParseOptions constructors if SourceCodeKind is Interactive or Script. [These changes should apply to the 'stabilization' branch only.] As a result of the changes, a significant number of unit tests are now skipped. (Search for SCRIPTING define and #2888 to find the test changes.)
-
由 Charles Stoner 提交于
-
- 22 5月, 2015 19 次提交
-
-
由 Tomas Matousek 提交于
-
由 AlekseyTs 提交于
Fixes #2774.
-
由 Dustin Campbell 提交于
Ensure that calls into EnvDTE.CodeModel work even if the underlying FileCodeModel has not been realized
-
由 Manish Vasani 提交于
Handle analyzers which have enabled rules, but no registered actions. Customer scenario: Analyzer author writes a bolier plate analyzer that defines the rule that it intends to implement in future, but registers no analyzer actions for analysis. Adding such an analyzer to your analyzer assembly brings down the entire analysis, and no analyzers execute during command line build. The issue was reported for StyleCopAnalyzers package which has many such to-be-implemented analyzers. Fixes #2980 Fix description: Add a null check around the place we compute set of all registered actions for analyzers. Testing: Added regression tests + existing tests.
-
由 Tomáš Matoušek 提交于
Improve debugging experience around exception filters
-
由 Manish Vasani 提交于
Customer scenario: Analyzer author writes a bolier plate analyzer that defines the rule that it intends to implement in future, but registers no analyzer actions for analysis. Adding such an analyzer to your analyzer assembly brings down the entire analysis, and no analyzers execute during command line build. The issue was reported for StyleCopAnalyzers package which has many such to-be-implemented analyzers. Fixes #2980 Fix description: Add a null check around the place we compute set of all registered actions for analyzers. Testing: Added regression tests + existing tests.
-
由 AlekseyTs 提交于
Ensure BoundLValueToRValueWrapper nodes are marked as compiler generated.
-
由 Paul Harrington 提交于
Port2966
-
由 Tomas Matousek 提交于
-
由 AlekseyTs 提交于
Fixes #2793.
-
由 Neal Gafter 提交于
Correct the copyright header on four files.
-
由 Neal Gafter 提交于
-
由 Dustin Campbell 提交于
Ensure that calls into EnvDTE.CodeModel work even if the underlying FileCodeModel has not been realized When calling into an EnvDTE.CodeModel API, the caller must pass the file name of the file to be operated on. For example: var ns = codeModel.AddNamespace("MyFile.cs", "MyNamespace"); However, the implementation EnvDTE.CodeModel would only ever succeed to find the FileCodeModel for "MyFile.cs" if had already been created and cached. If the FileCodeModel wasn't in the cache, the API that was called would throw. Ultimately, this comes down to a set of APIs with bad names that don't reflect that they only return cached values. This change renames those APIs to give them proper names (e.g. TryGetCachedFileCodeModelInstance) and adds an API that will retrieve a cached FileCodeModel or create a new one if needed.
-
由 Tomas Matousek 提交于
-
由 Manish Vasani 提交于
Fix cast simplification to not offer cast removals for following cases: 1. Explicit numeric casts in explicit checked/unchecked context 2. Non-identity pointer-to-pointer conversions. Fixes #2691 Description: Fix is to bail out early for these cases. As we are now more conservative, we cannot regress in offering any additional incorrect cast removals. #2987 tracks improving on this conservative approach post 1.0 milestone. Testing Done: Existing cast simplification tests. Approved by MattGe.
-
由 Manish Vasani 提交于
1) Explicit numeric casts in unchecked context 2) Non-identity pointer-to-pointer conversions. Fixes #2691 Description: Fix is to bail out early for these cases. As we are now more conservative, we cannot regress in offering any additional incorrect cast removals. Testing Done: Existing cast simplification tests.
-
由 Paul Harrington 提交于
-
由 Paul Harrington 提交于
-
由 Paul Harrington 提交于
Fix NullReferenceException in DependentProjectsFinder when we have an InternalsVisibleTo attribute with a null constructor arg.
-
- 21 5月, 2015 1 次提交
-
-
由 Tom Meschter 提交于
Generate relative paths correctly. **Bug:** Fixes #1579. **Customer Scenario:** The customer wishes to use a shared rule set file in their project to control their diagnostics. The .ruleset file is at the root of their solution, so the customer adds it to their project as a linked file. They then set it as the active rule set by right-clicking on the file in Solution Explorer and selecting "Set as Active Rule Set". The file should become the active rule set for the project, turning various diagnostics on or off or altering their severity. Instead the customer gets an error in the Error List: "The file '..\\..\\..\\Rule.ruleset' cannot be found" and the rule set has no effect. **Fix:** When adding `..` to the relative path to backup to higher-level directories, we effectively add each one multiple times. The fix is to stop doing that. **Testing:** I manually tested the following variation on the original scenario: * Rule set file in the same directory as the project file * Rule set file one level above the project file * Rule set file two levels above the project file * Rule set file up two levels and then down in a subdirectory * Rule set file one level below the project file * Rule set file two levels below the project file * Rule set file on a different directory and verified that in each case the project file ends up with the correct path, and that the rule set takes effect as expected. I also added unit tests to exercise the affected code.
-