Redesign the libsyntax and librustc APIs to make them more amenable to tooling

[bstrie]

http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccn50ti

I hope they can also innovate in the area of code navigation and code completion as well. It's not perfect in the C++ IDE world, and if you use something like Emacs of Vim it's even worse.

With the work in Rustdoc, and integration with LLVM, and the fact that Rust is orders of magnitude easier to parse than C++, IDE support shouldn't be a problem. What does need to be implemented is incremental compilation.

To get properly useful semantic code completion, libsyntax and librustc would need to be dramatically overhauled to get partial parsing working and to make it easier/possible to extract information like "what's the type of this variable" and "what methods can I call on this [mutable] variable."

There's long been sentiment that the APIs provided by libsyntax and librustc are kinda okay for tooling, but not great.

For another anecdote, this past weekend at MozSummit someone asked whether it would be possible to add Rust support to DXR (http://dxr.mozilla.org/), to which Graydon replied that it would be difficult (relative to clang, at least).

This is obviously sort of a nebulous "figure out the API" bug, but it's important enough that we'll have to start thinking about it sometime. Without a good tooling story, we won't be able to compete with C++.

[bstrie]

Nominating for Production Ready milestone.

[nrc]

Heh, that was me that asked Graydon about DXR :-) DXR support is coming along nicely, but we hack an extra phase into the compiler rather than using a nice API. Hopefully we can do better in the long run...

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#643