Account for use of try!() in 2018 edition and guide users in the right direction

[estebank]

Old documentation and blogposts will never be updated to not talk about the try macro. The current output of the following code

fn foo() -> Result<(), ()> {
    Ok(try!(Ok(())))
    
}

is

error: expected expression, found reserved keyword `try`
 --> src/main.rs:2:8
  |
2 |     Ok(try!(Ok(())))
  |        ^^^ expected expression

It should provide structured suggestions to either use r#try or ?:

error: use of deprecated `try` macro
 --> src/main.rs:2:8
  |
2 |     Ok(try!(Ok(())))
  |        ^^^^^      ^
  |        |
  |        deprecated `try` macro
  = note: in the 2018 edition `try` is a reserved keyword, and the `try!()` macro is deprecated
help: you can use the `?` operator instead
  |
2 |     Ok(Ok(())?))
  |        --      ^
help: alternatively, you can still access the deprecated `try!()` macro using the "raw identifier" syntax
  |
2 |     Ok(r#try!(Ok(())))
  |        ^^

This request is similar in spirit to #67204 and feels like a subset of #65148.

This issue has been assigned to @Duddino via this comment.

[Duddino]

@rustbot claim

[Duddino]

Would it be fine if I modified

rust/src/librustc_parse/parser/diagnostics.rs

Lines 1457 to 1476 in 534a41a

	pub(super) fn expected_expression_found(&self) -> DiagnosticBuilder<'a> {
	let (span, msg) = match (&self.token.kind, self.subparser_name) {
	(&token::Eof, Some(origin)) => {
	let sp = self.sess.source_map().next_point(self.token.span);
	(sp, format!("expected expression, found end of {}", origin))
	}
	_ => (
	self.token.span,
	format!("expected expression, found {}", super::token_descr(&self.token),),
	),
	};
	let mut err = self.struct_span_err(span, &msg);
	let sp = self.sess.source_map().start_point(self.token.span);
	if let Some(sp) = self.sess.ambiguous_block_expr_parse.borrow().get(&sp) {
	self.sess.expr_parentheses_needed(&mut err, *sp, None);
	}
	err.span_label(span, "expected expression");
	err
	}

and check if the try keyword is used, or is there another way to tackle this issue