Silence resolve errors if there were parse errors#116904
Silence resolve errors if there were parse errors#116904estebank wants to merge 2 commits intorust-lang:masterfrom
Conversation
|
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| ) { | ||
| Ok(kind) => kind, | ||
| Err(err) => { | ||
| self.sess.parse_errors_encountered.set(true); |
There was a problem hiding this comment.
This seems way more flow-dependent than just checking if we've emitted any session errors.
There was a problem hiding this comment.
For example, this doesn't protect against erroneous recoveries that don't result in a bubbled up Err value.
There was a problem hiding this comment.
Yeah, I experimented with silencing all resolve errors if there were any parse errors, but in practice it wasn't an improvement. The only place where the silencing really comes in handy is when parsing patterns fails, and the silencing should be only within that scope, not all resolve errors.
|
☔ The latest upstream changes (presumably #116849) made this pull request unmergeable. Please resolve the merge conflicts. |
Fix #74863.
In the following case:
we no longer emit resolution errors due to
urlandtitlenot being available, and more gracefully handle when a sub-pattern is missing a field name.