Type Library API & Declarations

[bclothier]

Reviewing the open issues for typelib API project, it appears to me that a necessary prerequisite step needs to be fulfilled; feeding the new information into Declarations.

Currently, the Declarations are basically immutable, and comes from the resolver exclusively. We need to integrate the new stream of data. While the resolver could be updated to consume the data from ComProject, there are other considerations.

1. Don't we want the ability to bypass the resolver and generate Declarations as-is from the type information alone? That would be useful in the scenarios of parsing the locked projects where we can't access the source code, and because parsing from ComProject is much faster, that information can be used to load up the Code Explorer without requiring a full parse of the source code. When a full parse is performed, the Code Explorer can be then updated with information and enable other features that are dependent on the full parse.

2. Do we want to make Declaration mutable in this case or keep it immutable, requiring a replace operation when we collect new metadata? Considering that there usually will be a large amount of overlap in the data between the type information API and from source code parsing, mutating only select set of members may be less work than replacing a entire Declaration, which usually has several pieces of information associated with it.

Tangentially, we need to consider the need to make ComReflection capable of generating multiple outputs. Currently, it generates what basically amounts to a DTO or POCO objects that is representative of the types found within the COM library. However, we may need it to generate Declarations, and one day, we may need it to generate the data to be then used in a replacement object browser (see #1093).

[MDoerner]

Regarding point 1, we are already able to produce declarations out of user COM projects and we do so for locked projects. This has been set up about a year ago already, I think; we simply did not switch on the user COM project generation.

Currently, we only generate the declarations for locked projects, but this can be extended to more projects by providing a larger set of project ids to the corresponding process step. Basically, the current setup was built to allow the exclusion from the usual process and inclusion into the process for locked project for a list of projects identified by filename. The idea was to build a UI such that the user can specify this list in order to exclude 3rd party projects from the usual process while still resolving references correctly.

[bclothier]

I think I'm confused because the declarations from user COM projects are generated as part of the parsing run, within the ParseCoordinator. The point 1 is more about being able to generate declarations without requiring a parse of the source code, the theory being that we would be able to collect metadata much faster using type information which would then enable code explorer to work without requiring a source code parse for example.

[MDoerner]

As far as I see it, point one contains two different things mixed together, generating declarations for locked projects and generating declarations on the side for to enhance the performance of some features. My comment was about the first aspect.
We do already generate declarations for locked project. What exactly is excluded from the usual parse and generated from the user COM projects is determined by our implementation of the IProjectsToResolveFromComProjectSelector interface.

Regarding point 2, I am against making the the declarations even more mutable because thins just causes more invalidation headaches. (You have to do the proper invalidation such that we get a clean start whenever we cancel in the middle of a parse.) I actually think they should become less mutable. This would mean that the references move to a separate storage only linked to the declaration via a key. We basically have such a storage already inside the DeclarationFinder with its multitude of lookups for references.