It's not as dire as you suggest. We can just allow some further passes to 
continue if earlier passes fail. We have this "ty_err" infrastructure in place 
already. Parsing creating an incomplete AST is also possible.

I don't really think that Go is that much easier to do completion on. Type 
inference in Rust is more powerful, sure, but Go has type inference too. Same 
with trait imports: it's all lexical in Rust, so that should work too. C++ is 
much worse, with its strange intertwined parsing and typechecking and template 
expansion, and Visual Studio does a good job with that. JetBrains offers code 
completion for Scala, which is more complex than Rust with implicits and such.

Patrick

On March 12, 2014 1:07:23 PM PDT, Daniel Micay <danielmi...@gmail.com> wrote:
>On 12/03/14 03:52 PM, Clark Gaebel wrote:
>> 
>>     ​There is no accurate jump-to-definition, type retrieval,
>docstring
>>     retrieval or semantic completion for Rust. The compiler was not
>built
>>     with support for this kind of tooling in mind, and I seriously
>doubt
>>     that anything but inaccurate hacks will exist for a *long* time.​
>> 
>> 
>> ​This worries me a lot.
>
>It would need to be able to perform type checking/inference even if the
>file can't be fully parsed, or there are type errors in other places.
>
>At the moment, each phase simply assumes all of the previous stages
>were
>fully completed, and it bails out immediately on any error by unwinding
>via failure.
>
>It's easy to see this from the error reporting. Rust can report
>multiple
>errors within the same phase, but it's unable to report a type error if
>parsing fails. `clang` was designed with this kind of thing as a
>central
>pillar and is able to continue reporting errors or giving useful
>results
>to queries from tooling even if there are problems.
>
>It's not at all an easy task, and most compilers are not able to do it.
>A language like Go is simple enough that tooling like completion can be
>done without help from a compiler. However, Rust has powerful local
>type
>inference, which presents a difficult obstacle. Another enormous
>obstacle is the power of traits - a type can have methods provided by
>traits, if the trait is in scope and the type is covered by an
>implementation, which may be generic.
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Rust-dev mailing list
>Rust-dev@mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to