Feature Request : Make internals public about roslyn

[nosami]

I wanted to return keywords like this - https://github.com/icsharpcode/NRefactory/blob/roslyn/ICSharpCode.NRefactory.CSharp/Features/Completion/ContextHandler/KeywordContextHandler.cs.

If the Recommender could return keywords, then I wouldn't need to use CSharpSyntaxContext

[JoshVarty]

Roslyn already has something like 7,000 public methods. Opening up every internal type/method would grow this number substantially.

I think it makes more sense to ask for individual types to be made public while explaining the problem it solves for you.

[nosami]

So far, I've wanted CSharpCodeGenerationService and FindDerivedTypesAsync.

How about making all methods that Visual Studio uses public? :)

[jmarolf]

The apis that are internal but used by Visual Studio have only been tested in the narrow scenarios that Visual Studio uses them in. Opening them up requires testing and design changes for a broader audience. That being said, we are trying to get through as much as we can. For example SyntaxGenerator is a new api that should allow you to do most of the things CSharpCodeGenerationService did, but in a language agnostic way.

So far I'm hearing

• CSharpSyntaxContext
• FindDerivedTypesAsync
• Intellesense API

Could people working on omnisharp expand this list and add short description of what you would use the api for?

[DustinCampbell]

With regard to keyword IntelliSense, we'd talked about doing that at one point if there was a request. (I'm guessing this is one!) The current recommendataion data API for the completion list was born out of a request from a browser-based host that was only showing completion on ".". So, keywords were unnecessary for that case.

As @JoshVarty say, simply making every internal API public isn't going to work. Most of these aren't even reasonable APIs. Like @jmarolf, I'd rather see sensible requests for specific APIs so that we can track them in milestones and make progress toward getting the necessary APIs exposed. Sound good?

[nosami]

Hey, I totally understand the reasons you have for not making everything public.

I'm just used to working with NRefactory, where everything was public from the beginning... and if any breaking changes were introduced, I'd just fix them. It was simple that way :)

OK.... just to be clear, I don't need CSharpSyntaxContext right now if you are planning on adding keywords to the Intellisense API. I would need it if you weren't planning on doing that, but I have no way of knowing :)

FindDerivedTypesAsync would be useful though... I currently have an extremely naive brute force version of this.

[mkrueger]

btw. from monodevelop PoV it's hard to replace NRefactory with roslyn for above reasons.

It's perfectly fine to use internals and internals visible to inside roslyn (in NRefactory we overused public maybe a bit too much). But I have one request:

Don't allow the Visual Studio side use internal roslyn API. All Visual Studio should be matched by the public API. Everytime you guys are using internal API for your own product there is something missing inside the roslyn API.

Without a huge set of public API roslyn fails it's goal.

[DustinCampbell]

@mkrueger we totally get that. It's for that reason that the IDE doesn't use internals from the compilers and only relies on compiler public APIs. The problem is that the Workspaces layer actually grew out of the IDE. It even used to have a dependency on the Visual Studio editor. So, we naturally had plenty of internal code that, when separated into layers, turned into internal APIs. Taking the time to properly expose more APIs to get rid of some of the "internals visible to ugliness" is definitely a goal, but each requires design work to create a sensible API. So, if you have specific API requests, please create issues for them. That's extremely helpful for us to get the prioritization right.

[nosami]

Which parts of Roslyn does VS use that wouldn't be useful to other IDEs / editors?

Pretty sure that I would use anything that you made public. Currently resorting to reflection hacks.

[tenor]

C# Pad uses the following types which are marked internal:

• enum Microsoft.CodeAnalysis.CSharp.ErrorCode
• class Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol
• property Microsoft.CodeAnalysis.CSharp.CSharpCompilation.GlobalUsings
• class Microsoft.CodeAnalysis.DiagnosticBag
• class Microsoft.CodeAnalysis.CSharp.DiagnosticBagExtensions
• method Microsoft.CodeAnalysis.CSharp.DiagnosticBagExtensions.Add (All overloads)

I added an InternalsVisible attribute to access them.
Changing these types to have a public access modifier requires that so many other types are changed as well to resolve inconsistent accesibility errors.

The VB counterparts of these types will also need to be changed.

[mkrueger]

I know that it's very problematic to make a good API for such a thing than Roslyn.

I would even be ok with API breaks from time to time :). As nosami already mentioned - we just 'fix' our stuff and go on with the new API.

Today I had problems with the Diagnostic API - but I opened a discussion about that in the API forum.

[sharwell]

I use the internal type DependentTypeFinder in my Inheritance Margin extension.

https://github.com/tunnelvisionlabs/InheritanceMargin/blob/566f0d677cccc431a2f146a9f567b3eec3e97485/Tvl.VisualStudio.InheritanceMargin.CSharp/CSharpInheritanceAnalyzer.cs#L70-L76

[sharwell]

@nosami and @jmarolf: you both mentioned FindDerivedTypesAsync. I can't find any such method in the code; are you referring to the methods in DependentTypeFinder or some other piece of code which is not in this repository?

[nosami]

@sharwell You are correct. I have a bad memory. I was referring to FindDerivedClassesAsync in DependentTypeFinder

[DustinCampbell]

@tenor, all of those are internal types in the compiler and aren't used by the IDE. It'd be great to understand what you're using them for in C# Pad to see if there's a need for a new public compiler API.

[nosami]

I wanted to use FindDerivedClassesAsync so that I could find implementations / overriden methods.

[tenor]

@DustinCampbell , I took another look and realized that NamedTypeSymbol and GlobalUsings are in some dead code that isn't referenced anymore.

I do use DiagnosticBag and ErrorCode but only because I needed to reimplement the ScriptEngine.
The ValidateReferences method which is part of the ScriptEngine references these types.
This may no longer be the case when the official ScriptEngine is released.

[mattwar]

FindDerivedClassesAsync looks like a candidate for an API to be exposed on SymbolFinder.

[MrJul]

Personally, I've needed SymbolEquivalenceComparer, it's the only way to correctly compare two symbols across compilation units, and it's unfortunately internal. ITypeSymbolExtensions could be public too, as it's mostly using already public API. Rewriting methods such as IsNullable, IsNumericType or GetBaseTypes is easy, but why should we when it's already here?

[JoshVarty]

SyntaxEquivalence is another class that might be worth considering making public.

[theoy]

@JoshVarty - I created issue #61 to separate out your request for SyntaxEquivalence, since this started out with more Workspace-oriented APIs. It might help because we may view each of the groups of API efforts independently, rather than force consensus on one mondo request (which may have contentious portions :) )

[gafter]

We will not blanket-public our internal APIs, as that would impose an unreasonable compatibility constraint on future evolution of the languages and compilers. If you have specific APIs that you need to be exposed, please file an issue for each one explaining what you need and why you need it. We will likely craft an appropriate API for those uses rather than exposing internal functionality.