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

Issue by bstrie
Tuesday Oct 08, 2013 at 13:34 GMT

For earlier discussion, see rust-lang/rust#9769

This issue was labelled with: A-tools, P-low in the Rust repository

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++.