[nem-en] Completion thoughts

[vc]

> I'm not sure why didn't you want to just return compiler's internal
> interfaces, like TypeInfo, IMember, IMethod, etc. They already have
> most methods you would need for filtering and
> obtaining full information about them.
> As you said, we should have a good way to obtain the type of given
> expression in program, but I think it should be returned directly as
> compiler API uses it. Then in any specific IDE integration it can be
> analysed and also compiler can be asked to provide any additional
> information. If compiler's interfaces lack some properties or methods,
> like IsVolatile, etc. we should add it there, not create artificial
> wrappers.

+1

> Such things can be easily filtered when we operate on compiler's
> structures.


But will be a beam if will higher-level the interface for these purposes.

> Problem with Save / RestoreState is that there is no clear sign when
> we can cleanup this storage. There are several fields, which must be
> saved in lexer:
> - line and column number

It is calculated from the line.

> - preparser stack state

It may be saved in Int16?

> - indentation syntax fields

What is it?

> > - Add / remove references on the fly
> 
> I think this requires rebuilding of any cached information in
> compiler, as changing referenced assemblies can invalidate any
> information used by compiler. But this is not bad, since usually
> references are not changed often.

References to external assembly change vary seldom. It is possible reparse
all project on it change.

> > - I would remove the information about Defines, as IDEs usually don't
> > use it to colorize
> 
> Standard Lexer uses it, so I don't see the point in removing it just
> for completion engine.

+1
 
> I see it in form of extending compiler's API or just adding utility
> methods in CompletionEngine, which would make such things easier, but
> still operate on compiler's structures.

+1

Vlad