Suggest removing leading left angle brackets.

[davidtwco]

Fixes #57819.

This PR adds errors and accompanying suggestions as below:

bar::<<<<<T as Foo>::Output>();
     ^^^ help: remove extra angle brackets

r? @estebank

[davidtwco]

I'm not sure how this interacts with #57817 if there are both extra trailing and leading angle brackets.

[estebank]

A cursory look at the code tells me that's fine, but I wonder how often this case happens as opposed to missing trailing brackets. What's the output of this PR for the following?

println!("{:?}", vec![1, 2, 3].into_iter().collect::<Vec<usize>());
println!("{:?}", vec![1, 2, 3].into_iter().collect::<<<Vec<usize>>());
println!("{:?}", vec![1, 2, 3].into_iter().collect::<<<Vec<usize>>>());
println!("{:?}", vec![1, 2, 3].into_iter().collect::<<Vec<usize>>>());
bar::<<T as Foo>::Output();

[davidtwco]

A cursory look at the code tells me that's fine, but I wonder how often this case happens as opposed to missing trailing brackets. What's the output of this PR for the following?

I've put the output of this PR as well as the output of this PR and #57817 at the same time in this gist. I think this behaves appropriately.

[estebank]

I am slightly worried about the snapshot usage here (which again, it might be fine), but I'm thinking that we might be able to use unmatched_angle_bracket_count in expected_one_of...

[estebank]

@bors try

[bors]

⌛ Trying commit 22f794b with merge 100d423c5c506b60b6ab591dfea5515f65a7fb74...

[estebank]

By the way, I love the level of recovery.

With the introduction of unmatched_angle_bracket_count we can make expected_one_of much smarter. If > is in the list, like in the following example, we could actually give a suggestion and recover:

error: expected one of `,`, `->`, `::`, or `>`, found `;`
 --> test.rs:6:31
  |
6 |     bar::<<T as Foo>::Output();
  |                               ^
  |                               |
  |                               expected one of `,`, `->`, `::`, or `>` here
  |                               help: likely there's a missing `>` here

[bors]

☀️ Test successful - checks-travis
State: approved= try=True

[estebank]

@bors try

[bors]

⌛ Trying commit 8ab12f6 with merge de98dc84921c98aec5fe83cceb4cda42ba22e555...

[estebank]

@rust-timer build 100d423c5c506b60b6ab591dfea5515f65a7fb74

[bors]

☀️ Test successful - checks-travis
State: approved= try=True

[estebank]

@rust-timer build de98dc84921c98aec5fe83cceb4cda42ba22e555

[rust-timer]

Insufficient permissions to issue commands to rust-timer.

[Mark-Simulacrum]

@rust-timer build de98dc84921c98aec5fe83cceb4cda42ba22e555

I've also added you to the list

[rust-timer]

Success: Queued de98dc84921c98aec5fe83cceb4cda42ba22e555 with parent 19f8958, comparison URL.

[rust-timer]

Success: Queued de98dc84921c98aec5fe83cceb4cda42ba22e555 with parent 19f8958, comparison URL.

[estebank]

@rust-lang/compiler I'm looking at the perf results and it looks reasonable to me for the most part, but there are some 5% worst case swings in cycles:u and cpu:clock for two of the tests. I'm tempted at approving unless anyone has any objections. Memory usage had the biggest hit (9% for webrender-debug for a clean compile).

[nikomatsakis]

My suspicion, @estebank, is that these results are mostly noise. This is my reasoning, let me know if you see a flaw:

• This code is adding overhead to the parser.
• Presently, the parser runs in ALL scenarios.
• However, looking at the comparison link, I see a few random slowdowns that only affect one scenario (example below). I would expect some effect on all scenarios.

For example, consider these results:

unicode_normalization-check	avg: 0.6%	min: -0.3%	max: 1.7%
clean-check	39,380,205,064.00	40,057,925,965.00	1.7%
nll-check	40,821,023,751.00	40,814,681,209.00	-0.0%
baseline incremental-check	47,085,578,219.00	47,768,957,881.00	1.5%
clean incremental-check	1,360,091,673.00	1,356,348,397.00	-0.3%
patched incremental: println-check	41,251,067,880.00	41,249,853,473.00	-0.0%

Here, I would think that if the parser got slower, and it was affecting the "baseline incremental" run (which means the first incremental run, with no prior state), then it ought to affect "clean incremental" even more so -- as clean incremental does the same amount of parsing, but does a lot less other work.

So the main question is whether I am correct that the overhead here would be focused on the parser, I guess. If so, I think it's fine.

[estebank]

I agree that this is only parser overhead. The only regression that seemed relevant was memory usage for webrender-debug for a clean compile of 9% , but even that seems a bit high. Regardless, the parser is a small portion of where rustc spends time, so I feel comfortable merging this. There are also a couple of small tweaks I want to build on top of this.

@bors r+

[bors]

📌 Commit 8ab12f6 has been approved by estebank

[bors]

⌛ Testing commit 8ab12f6 with merge 46a43dc...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: estebank
Pushing 46a43dc to master...