D Compiler as a Library

[Jacob Carlborg]

On 2012-04-13 11:58, Ary Manzana wrote:
> Having a D compiler available as a library will (at least) give these
> benefits:
>
> 1. Can be used by an IDE: D is statically typed and so an IDE can
> benefit a lot from this. The features Descent had, as far as I remember,
> were:
> 1.1. Outline
> 1.2. Autocompletion
> 1.3. Type Hierarchy
> 1.4. Syntax and semantic errors, showing not only the line number but
> also column numbers if it makes sense
> 1.5. Automatic import inclusion (say, typing writefln and getting a list
> of modules that provide that symbol)
> 1.6. Compile-time view: replace auto with the inferred type, insert
> mixins into scope, rewrite operator overloads and other lowerings (but
> I'm not sure this point is really useful)

Sure it is, it's very usable.

> 1.7. Determine, given a set of versions and flags, which branches of
> static ifs are used/unused
> 1.8. Open declaration
> 1.9. Show implementations (of an interface, of interface's method or,
> abstract methods, or method overrides).
> 1.10. Propose to override a method (you type some letters and then hit
> some key combination and get a list of methods to override)
> 1.11. Get the code of a template when instantiated.
> 2. Can be used to build better doc generators: one that shows known
> subclasses or interface implementation, shows inherited methods, type
> hierarchy.
> 3. Can be used for lints and other such tools.
>
> As you can see, a simple lexer/parser built into an IDE, doc generator
> or lint will just give basic features but will never achieve something
> exceptionally good if it lacks the full semantic knowledge of the code.
>
> I'll write a list of things I'd like this compiler-as-library to have,
> but please help me make it bigger :-)

* Show generated documentation for symbols both on hover and in the 
autocompletion list
* Show source for symbols
* Import organizer (or what to call it). Remove unused imports and add 
missing ones
* Code formatting
* Fix it/quick fix. Button for automatically fixing simple errors
* Syntax and semantic highlighting :)
* Refactoring

I can also think about a lot of features that is usable if you also have 
a GUI builder in the IDE.

> * Don't use global variables (DMD is just thought to be run once, so
> when used as a library it can just be used, well, once)
> * Provide a lexer which gives line numbers and column numbers
> (beginning, end)
> * Provide a parser with the same features
> * The semantic phase should not discard any information found while
> parsing. For example when DMD resolves a type it recursively resolves
> aliasing and keeps the last one. An example:
>
> alias int foo;
> alias foo* bar;
>
> bar something() { ... }
>
> It would be nice if "bar", after semantic analysis is done, carries the
> information that bar is "foo*" and that "foo" is "int". Also that
> something's return type is "bar", not "int*".
> * Provide errors and warnings that have line numbers as well as column
> numbers.
> * Allow to parse the top-level definitions of a module. Whit this I mean
> skipping function bodies. At least Descent first built a the outline of
> the whole project by doing this. This mode should also allow specifying
> a location as a target, and if that location falls inside a function
> body then it's contents are returned (useful when editing a file, so you
> can get the outline as well as semantic info of the function currently
> being edited, which will never affect semantic in other parts of the
> module). This will dramatically speed up the editor.
> * Don't stop parsing on errors (I think DMD already does this).
> * Provide a visitor class. If possible, use visitors to implement
> semantic analysis. The visitor will make it super easy to implement
> lints and to generate documentation.

This is a great start and as I've said elsewhere, this would be so cool 
and usable to have.

-- 
/Jacob Carlborg