dmd support for IDEs
Michel Fortin
michel.fortin at michelf.com
Sun Oct 11 05:13:48 PDT 2009
On 2009-10-11 01:57:08 -0400, Walter Bright <newshound1 at digitalmars.com> said:
> You're certainly welcome to take the compiler front end and try and
> make a dll out of it or integrate it directly into an IDE. But what I
> suggested would probably get a lot of results for a minimal investment
> in the front end and a minimal investment in existing IDEs.
And I've already done so in D for Xcode (with an old version of DMD).
I had to change the error handling to throw exceptions on errors (no
call to exit in my IDE please!). I also added some data to tokens to
get their exact range in the file allowing me to use the DMD lexer for
syntax highlighting. The semantic also did preserve that information
and could tell you in what class, template, or function your insertion
point was on a per-character basis.
And then I stopped there. This is a pain to maintain when DMD gets
updated, so I didn't. It's buggy because if the compiler crashes, the
IDE crashes too (keep in mind that parsing incomplete code every few
seconds has a tendency to cause more crashes than regular compilation).
And finally, Xcode 3 came with a much better syntax definition format
and a complete revamp of syntax highlighting that obsoleted half the
integration work I did. So the next version of D for Xcode will get rid
of DMDFE as an internal component and use Xcode's built-in machinery.
It's not clear to me how much getting supplementary data from the
compiler could help. If I only get what I can see through Ddoc, it's
only half useful. I can already parse and get character ranges for the
the high-level constructs (classes, tempaltes, functions, etc.). What
will be harder is matching each symbol in function code to the correct
definition because that depends on the context of the function and
doing autocompletion for what you type depending on what's available in
a given context.
> Experience also suggests that using fork/exec rather than a shared dll
> approach is much more robust and easier to develop. The reason is that
> the former uses separate processes, which cannot step on each other.
> The latter puts everything in one process space, where you've got all
> the lovely, time-consuming, hair-pulling concurrency problems. The
> utter failure of the parse process also cannot bring down the IDE.
Indeed, you don't want the compiler to crash your IDE.
Also, can DMD accept D files from stdin? That way files wouldn't need
to be saved on disk on each keystroke.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list