Error E0046 should be the last one to report

[shahuwang]

struct Context;  

trait ctx{

  fn f1(&self) -> String;  

  fn f2(&self) ;

}

impl ctx for Context{ 

  fn f1(&self) -> String{

     // code here

  }

}   

During coding, I always need to run 'cargo build' to check whether it is right, but for the code above, it always report "error: not all trait items implemented, missing: f2 [E0046]
error: aborting due to previous error",

It is ok that only one or two methods of the trait that need to be implemented,but if the trait has ten methods, I have to implement all of them before I can check whether method f1 is implemented right, without syntax error.

I wish that E0046 be reported as the last one.

[KalitaAlexey]

I want to do it. I need a mentor.

[KalitaAlexey]

It seems the compiler checks whether a trait implementation is full before whether a function returns value.

@shahuwang The compiler checks for syntax errors before both. To check this try code

struct Context;  

trait ctx{
  fn f1(&self) -> String;  
  fn f2(&self) ;
}

impl ctx for Context{ 
  fn f1(&self) -> String{
      abc
  }
}   

[brson]

cc @rust-lang/compiler @KalitaAlexey needs help implementing this

[nikomatsakis]

@KalitaAlexey feel free to contact me over IRC (nmatsakis) or via e-mail. The check is currently taking place in the "collect" phase of type checking (src/librustc_typeck) and I think it will have to be moved until after the other phases. Probably fairly straightforward. I don't have time to dig into the details just now though (about to head off for the night). But do contact me or at least remind me tomorrow and I'll try to post up some more links into the code. :)

[KalitaAlexey]

@nikomatsakis May be some checks depend on trait impl check. I will check it.

[nikomatsakis]

So I'm wondering -- rather than moving this check later, another possibility might be to try and remove the flag to abort when errors are detected. In general, we should probably do fewer such aborts. On the other hand, that's a more general change that will probably lead to a wave of ICEs as we correct the downstream code. So maybe not something we should do for now.

But in general I am a bit nervous that we'll wind up with downstream type inference failures and other errors whose true cause is the lack of an associated type or something, but that cause is somewhat obscured. Already @KalitaAlexey is encountering this problem, but we'll have to see if it is readily fixable.

[arielb1]

The check actually runs during the "item-types checking" phase of type-checking. We added an abort_if_errors after the check back in the day to stop these kinds of issues from ICE-ing rustc.

Maybe we can allow for compilation to continue with missing methods, as they are not really used until trans anyway.

[nikomatsakis]

In general, it seems like (for IDE support and other reasons) it'd be
better to try and start removing some of these hard phases. But I do
predict a series of ICEs that will take some time to fully eradicate.

On Wed, Jan 20, 2016 at 01:57:37PM -0800, arielb1 wrote:

The check actually runs during the "item-types checking" phase of type-checking. We added an abort_if_errors after the check back in the day to stop these kinds of issues from ICE-ing rustc.

Maybe we can allow for compilation to continue with missing methods, as they are not really used until trans anyway.

---

Reply to this email directly or view it on GitHub:
#30999 (comment)