dmd support for IDEs

[Ellery Newcomer]

There are several core features that I absolutely must have (because I
want them):

1. autocompletion. everywhere. for everything. including local
variables. And that's not just the *pop* this symbol is a <type> that
does <ddoc>. It includes the completion part. When I type foreach
Ctrl+Space, I get a generic foreach statement (which is consistent with
the current compiler's syntax).

2. usage finding. I'm at a symbol. I want to know everywhere it's used.
If it's a class, I want to know everywhere it's subclassed.

3. code formatting.

4. build system

5. syntax highlight and code folding (easy peasy, but necessary)

6. error reporting aka dem shquiggly red lines

7. import resolution.

On top of these are a bunch of peripheral features:
When you have 1, code navigation should come pretty easy.
When you have 2, renaming any variable should come pretty easy.

When I have problems with those dang cyclic dependencies, I might want
to be able to merge two modules together.

etc


What I wanted out of my semantic analysis was a complete syntax tree and
symbol table that could make all of these things possible. If I can get
this direct from the compiler, it would obviously save me several years
of work and "yeah, this doesn't even try to be compatible" problems.


Walter Bright wrote:
> Ellery Newcomer wrote:
>> ctfe. compile time (weird connection?). what do string mixins evaluate
>> to?
> 
> No
> 
>> can I look at their result from the ide?
> 
> No

Well I want this feature.

> 
>> what do templates expand
>> to?
> 
> No
> 
>> what does this here alias/typedef represent?
> 
> Yes
> 

Good.

>> what does this here
>> typeof expand to?
> 
> No
> 
>> what does this here c-style type normalize to (in
>> d-style)?
> 
> No
> 

Well I want this feature.


>> As for other transformations, it seemed like Ary had some neat tricks in
>> descent that showed things like int i; going to int i = 0; etc. maybe
>> wistful thinking.
>>
>> while we're at it,
>>
>> when I see a symbol, can I find its type?
> 
> Yes

Good.

> 
>> can I find every symbol that
>> would follow it in a dot list/exp?
> 
> Yes

Good.

> 
>> when I see a symbol, can I find everywhere it's used?
> 
> No, but could be added
> 

Good.

>> when I see a scope, can I see every symbol that's in it?
> 
> Yes
> 

Good.

>> when I see a module, can I find everywhere it's imported?
> 
> Yes

Good.

> 
>> can I see exactly what symbols are pulled in?
> 
> No, but could be added

Good.

> 
>> Can I perform analysis to
>> show me where those dang cyclic dependencies are?
> 
> Don't know
> 

If I have the previous two I think I can do it. I might need a view of
the code after compile time expansions. Oh, and I'd obviously need to
see which modules have static ctors/dtors.

>> when I see source code, can I perform a simple walk over the xml to
>> format it?
> 
> No
> 
> 
> Think of what it provides as very similar to what ddoc does, except that
> instead of being in a human-readable format it would be a
> machine-readable one.

Yep, we're thinking of different things.

> 
> In other words, for each module you'll be able to get
> 
> . all the symbols in that module, and the members of those symbols
> (recursively)
> . the file/line of the source location of each symbol
> . the ddoc comment for each symbol
> . the type of each symbol
> 
> Things could be added over time, I was just thinking of this for starters.