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