When recovering `char`s, still give them the `char` type, instead of `&str`

[estebank]

test/ui/parser/lex-bad-char-literals-3.stderr shouldn't emit a type error.

[estebank]

This line would have to be changed to use token::Char:

rust/src/libsyntax/parse/lexer/mod.rs

Line 1448 in 8e2063d

return Ok(token::Literal(token::Str_(Symbol::intern("??")), None))

Ideally, we would add a new literal type Err here

rust/src/libsyntax/parse/token.rs

Lines 59 to 69 in 8e2063d

	#[derive(Clone, PartialEq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)]
	pub enum Lit {
	Byte(ast::Name),
	Char(ast::Name),
	Integer(ast::Name),
	Float(ast::Name),
	Str_(ast::Name),
	StrRaw(ast::Name, u16), /* raw str delimited by n hash symbols */
	ByteStr(ast::Name),
	ByteStrRaw(ast::Name, u16), /* raw byte str delimited by n hash symbols */
	}

that will later be interpreted to be of type TyErr, in order to avoid having any type errors involving this problematic literal, regardless of wether a &str or a char were expected.

[JohnTitor]

@estebank I wanna tackle this, but I don't know how to add a new literal type Err.
If you have time, please tell me.

[estebank]

@JohnTitor That would be the "hard" way of solving this. That would entail adding a new Lit variant, in the code linked above, deal with the fallout of doing so (most likely by ignoring it in most places) and transforming it to a TyErr when giving it a type (it is receiving TyStr at the moment). You should be able to find it by following the errors after adding the variant, but if not ping me and we can look at it together.

[JohnTitor]

@estebank I want to open a PR for fixing this issue, can I ask you to review?

[estebank]

@JohnTitor of course! Just add r? @estebank to the description of the PR.