- 19 11月, 2016 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 13 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 11 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 09 9月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 21 7月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 18 12月, 2015 1 次提交
-
-
由 Cyrus Najmabadi 提交于
-
- 11 11月, 2015 2 次提交
-
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
- 16 10月, 2015 1 次提交
-
-
由 Paul Harrington 提交于
-
- 10 9月, 2015 1 次提交
-
-
由 Cyrus Najmabadi 提交于
-
- 09 9月, 2015 1 次提交
-
-
由 Cyrus Najmabadi 提交于
-
- 05 9月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 11 6月, 2015 1 次提交
-
-
由 David Poeschl 提交于
Fixes #3303 This is a very similar crash to the one from #2352. This change reverts the specific fix that was done for that bug and instead generally ensures that all potential declaration conflict spans are calculated into reverseMappedLocations before calling AddDeclarationConflictsAsync when processing the project that contains the rename symbol's declaration. This also updates the RenamedSpansTracker.GetResolutionTextSpan(TextSpan, DocumentId) test hook, which maps original spans to post-rename spans, to correctly handle documents that were not changed during the rename operation. This change is needed because the RenamedSpansTracker does not track unresolved conflicts in unmodified locations (see the similar existing comment in InlineRenameReplacementInfo.GetNonComplexifiedReplacements for confirmation of this), and changing that for "1.0 (stable)" is potentially risky as many things query the state of the RenamedSpansTracker.
-
- 10 6月, 2015 1 次提交
-
-
由 Charles Stoner 提交于
-
- 29 5月, 2015 2 次提交
-
-
由 David Poeschl 提交于
Fixes #2352 This change fixes a rename crash that would occur when a method declaration conflict was introduced in a file with no references to that symbol, but where at least one other document in the same project had a reference to that symbol. When processing an individual project in ResolveConflictsAsync, we start with the full set of documents from _documentsIdsToBeCheckedForConflict related to that project. But, each rename phase can adjust this set of documents (called documentIdsThatGetsAnnotatedAndRenamed locally) to whatever documents are represented by the current set of _conflictLocations, which can exclude the _documentIdOfRenameSymbolDeclaration itself if it contains no references. Now, when documentIdsThatGetsAnnotatedAndRenamed is recalculated we make sure to keep the _documentIdOfRenameSymbolDeclaration in the set if we're processing the project that contains it.
-
由 David Poeschl 提交于
Fixes #2352 This change fixes a rename crash that would occur when a method declaration conflict was introduced in a file with no references to that symbol, but where at least one other document in the same project had a reference to that symbol. When processing an individual project in ResolveConflictsAsync, we start with the full set of documents from _documentsIdsToBeCheckedForConflict related to that project. But, each rename phase can adjust this set of documents (called documentIdsThatGetsAnnotatedAndRenamed locally) to whatever documents are represented by the current set of _conflictLocations, which can exclude the _documentIdOfRenameSymbolDeclaration itself if it contains no references. Now, when documentIdsThatGetsAnnotatedAndRenamed is recalculated we make sure to keep the _documentIdOfRenameSymbolDeclaration in the set if we're processing the project that contains it.
-
- 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.
-
- 12 3月, 2015 1 次提交
-
-
由 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.
-
- 01 2月, 2015 1 次提交
-
-
由 beep boop 提交于
Background: As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation. https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style The coding style transition is automated using a Roslyn based rewrite tool: https://github.com/dotnet/codeformatter This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens. Note: this is a soft style requirement. There are no build errors that come from this change. (changeset 1408227)
-
- 15 1月, 2015 1 次提交
-
-
由 jaredpar 提交于
-
- 14 1月, 2015 1 次提交
-
-
由 RoslynTeam 提交于
-
- 16 11月, 2014 1 次提交
-
-
由 chandera 提交于
The current cost-based cache has no domain knowledge of whether items will be needed again or are safe to collect. It is therefore usually over-sized. This change implements an explicit cache that must be enabled by consumers. The cache will hold trees and compilations as needed and release them when clients are done with them. Currently, we enable explicit caching of the active document. Rename tracking and the solution crawler also request caching for each project they process. (changeset 1372494)
-
- 13 11月, 2014 1 次提交
-
-
由 Pilchie 提交于
Add a diagnostic (not yet part of the toolset) to ensure CancellationToken arguments are last* and fix violations. * Unless they are followed by params, out, ref, or optional parameters (without themselves being optional), or are interface implementations or overrides. * I suppressed the warnings in the TaskExtensions and TaskFactoryExtensions types, since we're trying to mirror the TPL's APIs there. Includes some tests for C# scenarios, and a fixer for C# that just reorders the signature (arguably, it's better to just let the user invoke Change Signature themself). (changeset 1370978)
-
- 07 10月, 2014 1 次提交
-
-
由 jasonmalinowski 提交于
This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support. This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion. This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio. Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)
-
- 22 7月, 2014 1 次提交
-
-
由 kayleh 提交于
When renaming locals, parameters, private fields, etc, we should not rename comments/strings in files that would otherwise be unaffected by rename. Also fixing typo in ProjectDependencyGraph.GetProjectsThatDirectlyDependOnThisProject. (changeset 1300742)
-
- 23 5月, 2014 1 次提交
-
-
由 kayleh 提交于
-
- 10 4月, 2014 1 次提交
-
-
由 mattwar 提交于
FeaturePacks have changed to become HostServices. IWorkspaceServiceProvider has become HostWorkspaceServices ILanguageServiceProvider has become HostLanguageServices HostWorkspaceServices can be accessed directly from Workspace.Services. HostLanguageServices can be accessed directly from Project.LanguageServices. Some of the existing workspace and language services have been made public. (changeset 1226729)
-
- 21 3月, 2014 1 次提交
-
-
由 mattwar 提交于
This changes removes the ProjectDependencyService and replaces the Solution's itnernal transitive dependency tracking with the ProjectDependencyGraph. After the change removing async projects from solutions, the service was no longer necessary, as dependency graphs (mostly on demand) can be computed and reused for most solution branching. The solution's internal transitive dependency tracking then became redundant. (changeset 1210210)
-
- 19 3月, 2014 1 次提交
-
-
由 Pilchie 提交于
-