[Monodevelop-devel] Changes to resoving/ast/type system

[Lluis Sanchez Gual]

> 
> Even if the usage is 'mostly' the same the model is very different:
> - CompilationUnits (are now called IParsedFile) are now always stored 
> correctly (this info is never lost).
> - The resolving of return types is done at call time. There is no real 
> way to do it clean without that, but the resolver is lighting fast and 
> correctness > speed. This resolves some issues we had (like changing 
> namespaces, makes it possible to use 'external aliases')

Will this resolution of types be transparent? that is, if I get for example the list of fields of a class and I want to get the type of each field, will I have to make a call to resolve each type or will the type system resolve the type for me when I query it?

> - IType and the definition are now 2 classes
> IType is that what 'InstantiatedType' was and ITypeDefinition is the 
> real definition in file. You won't need ITypeDefinition very often - 
> most stuff is done with IType.
> 
> While consuming code should be easy to translate dom parsers are a bit 
> harder to translate (but again - mostly the same). Atm we've c# and 
> cecil as type system source - and I think that nrefactory.vb has a type 
> system converter + parser + ast for vb.net. Ovearall the new type system 
> feels a lot more like a 'high level' api, which is a good thing.
> 
> - Resolver changes
> The new resolver infrastructure changes internally very much - the old 
> one basically took an expression and a position in the file. Then it 
> gave you a resolve result. The new resolver resolves a 'set' of ast 
> nodes. And then it analyzes the ast with the 'set' (the set should 
> contain all parents of the node to resolve, all other nodes are 
> skipped). I intend to hide the resolver internals from the users, so 
> that they do not need to care about that (In fact I keep the resolver 
> backend mostly intact - but the ResolveResults change - the new resolver 
> brings own results, but consuming code is very easy to translate).
> What I can say is that the new one + infrastructure is very fast to use :)
> 
> ... I don't know when I do the commit, but the ast/type system/resolver 
> is all in NRefactory - I just translate our infrastructure over. Atm I 
> broke some things - for ex. the refactoring infrastructure & c# code 
> completion. But semantic highlighting works and it seems to be usable 
> now :) - context actions are in place as well. I think that I'll commit 
> around friday (y, I want to get sure I didn't break anything and I need 
> to fix some issues that are only working 80%  - I commented out some 
> functions that I didn't find not so important for ex. in the code 
> metrics or unit tests) + I can't tell how long I need for the code 
> completion.

Right now, we can't afford de-stabilizing master. You should commit those changes in a branch and make it public. Then we can test it and when everything is ready, we can merge to master.

Lluis.