Better diagnostics when concatenating strings

[Manishearth]

A lot of people come from other languages and expect "a" + "b" to work, or x + y where x and y are both Strings.

We should be suggesting "a".to_string() + "b" in the first place, x + &y in the second, and in both cases also recommend using format!() instead.

Context: https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_disappoints_me/dccdi17/

[mgattozzi]

I'd like to take a stab at this if I could get some guidance as to where things in the compiler need to be changed and how.

[Manishearth]

Sure! What you need to do is find the place in the code which emits the error on "a" + "b" (hint: error code E0369)

Somewhere there you'll want to add an if checking that the operation is add, and then check that the LHS and RHS are both &str (we'll deal with the String + String/&str + String ones later). In that code, the Ty values (lhs_ty and rhs_ty_var) hold these types. They contain TypeVariants, and &str is basically TyRef(TyStr).

Then, span_note! about it. Once you have this going I can help convert the note into a suggestion.

[mgattozzi]

I'll be home soon so I'll get working on it then

[Manishearth]

Cool. You can ask me (or others) for help in #rust-internals if you need it.

[mgattozzi]

I found where after a bit of prodding so I think I have this part but if I run into problems I'll definitely jump on #rust-internals

[andersk]

For the String + String → String + &String part, that suggestion actually applies to anything that wants &str and is incorrectly passed String instead of &String, right? I don’t think concatenation is special.

It could even apply to anything that wants &T and is incorrectly passed U instead of &U where U: Deref<T>, though maybe that’s trickier.

[Manishearth]

Yeah. It's just that the concatenation stuff is handled separately.

I was planning on investigating this (or help someone investigate this) after this bug is fixed, by refactoring the functionality introduced here into a separate function that gets used in multiple error cases.

[mgattozzi]

@Manishearth here's the WIP that I have now: https://github.com/mgattozzi/rust/commit/007d45926f920b51cfab9924f0ee6461f527a2aa

Here's the output though:

michael@eva-02 ~/Code/rustc (git)-[better-string-message] % ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc string.rs
_
error[E0369]: binary operation `+` cannot be applied to type `&str`
 --> string.rs:4:20
  |
4 |     println!("{}", s1.as_str() + s2.as_str());
  |                    ^^^^^^^^^^^
  |
note: You can't use `+` between a &str and &str
 --> string.rs:4:20
  |
4 |     println!("{}", s1.as_str() + s2.as_str());
  |                    ^^^^^^^^^^^

error: aborting due to previous error

It seems the rhs_ty_var doesn't have a type that can be matched against. Is there some way to check for it here?

[Manishearth]

Hmm, _ is a TyInfer. Does it work with string literals?

You also might want to restructure the code so that the "an implementation of {} might be missing for {}" doesn't need to be repeated. It's fine for now if that note is unconditionally emitted.

[mgattozzi]

Let me try it out with string literals to see if I get something different.

[mgattozzi]

No it doesn't work. It looks like unless we identify what TyInfer is we won't be able to check the type. This is probably due to the note in the source code here: https://github.com/mgattozzi/rust/blob/007d45926f920b51cfab9924f0ee6461f527a2aa/src/librustc_typeck/check/op.rs#L178-L183

[Manishearth]

ugh. You could check the AST if it's a literal but that's not so great.

Would there be a way of extracting this info? @eddyb ?

[eddyb]

Checking for a literal is okay-ish. You might be able to type-check the RHS before emitting the error, giving you the missing information. cc @nikomatsakis