Wrong error when lifetime is appended to associated type

[mqudsi]

error[E0404]: expected trait, found enum `std::result::Result`
   --> src/imessage/db.rs:216:44
    |
216 | fn unwrap_iter<'a,T,E>(iter: Iterator<Item=std::result::Result<T,E> + 'a>) -> Result<Vec<T>>
    |                                            ^^^^^^^^^^^^^^^^^^^^^^^^ not a trait

In the code fragment above, the problem is not that Item needs to point to a trait (is that even acceptable?) but rather that + 'a can only come after a trait.

Ideally, this should actually be a different error ("lifetime specification here is not valid" or something along those lines) with the source of the error being the presence of 'a and not the definition of Item, but if it remains E0404 then at least a hint should be provided along the lines of

+ 'a can only follow a trait, but std::result::Result<...> is a type

[estebank]

Triage: no change.

[woshilapin]

I actually ran into the same problem where the compiler message actually send me in the wrong direction until I realized not a trait was not the problem. Here is a very simple example without any associated type to understand the problem.

The following code compiles just fine (playground).

struct A;              
                       
fn f() -> A {
    A                  
}                      

but if I add the lifetime in the return type (playground)

struct A;              
                       
fn f() -> A + 'static {
    A                  
}                      

I get this weird compiler message about not a trait

error[E0404]: expected trait, found struct `A`                     
 --> src/lib.rs:3:11                                               
  |                                                                
3 | fn f() -> A + 'static {                                        
  |           ^ not a trait                                        
                                                                   
warning: trait objects without an explicit `dyn` are deprecated    
 --> src/lib.rs:3:11                                               
  |                                                                
3 | fn f() -> A + 'static {                                        
  |           ^^^^^^^^^^^ help: use `dyn`: `dyn A + 'static`       
  |                                                                
  = note: `#[warn(bare_trait_objects)]` on by default              
                                                                   
error: aborting due to previous error; 1 warning emitted           
                                                                   
For more information about this error, try `rustc --explain E0404`.

Expected

I'd expect an error message explaining that Types cannot be mixed up with a lifetime constraint. Either trait is mixed with lifetime constraint, or types without constraints.

[estebank]

Would this output have been clear to you?

error[E0404]: expected trait, found struct `A`
 --> fil7.rs:2:11
  |
2 | fn f() -> A + 'static {
  |           ^ not a trait
  |
help: `+` can be used to constrain a "trait object" type with lifetimes or auto-traits, structs and enums can't be bound in that way
 --> fil7.rs:2:11
  |
2 | fn f() -> A + 'static {
  |           ^^^^^^^^^^^

[mqudsi]

@estebank that's definitely significantly better than what we currently have. I'd prefer a less obviously "parser state machine error" over E0404 and the accompanying text in your screenshot, but I can't really come up with a good option that isn't overly specific to this exact syntatic error. My rationale is that, devoid of any context, A + 'static is most likely an error with the + 'static (i.e. overall design of the function) rather than a mistake in using A, simply because it is easier for a developer to rationalize about trait vs struct than it is to rationalize about lifetime constraints.

Perhaps something along the lines of e.g. "E0xxx: Invalid combination of non-trait type and type constraint"? (Everything past the first line is fine, this is just about the error code and brief text.)

[estebank]

I wouldn't go as far as saying that this is the most likely interpretation. This could be just a simple typo, but that is covered as well:

[woshilapin]

It's definitely an improvement. Thank you @estebank