Do not emit inference errors after encountering mod parse errors#151883
Do not emit inference errors after encountering mod parse errors#151883estebank wants to merge 1 commit intorust-lang:mainfrom
mod parse errors#151883Conversation
Even in the face of parse recovery of a `mod`, when encountering parse errors silence knock-down inference errors. For conctex, in a repro project with a single parse error goes from emitting 69 diagnostics to 1.
|
Some changes occurred in need_type_info.rs cc @lcnr |
|
I'm unhappy with adding the |
|
@rustbot reroll |
|
looks good for me, add a test for it? |
|
@chenyukang I'm gonna need a hand to come up with a minimized repro suitable for the test suite. |
There was a problem hiding this comment.
This fix feels somewhat weird to me. It seems both very broad (in that it entirely silences ambiguity errors if there was any parse error) and overly specific (why only silence ambiguity errors)
What are the specific cases where a mod parse error causes ambiguity?
I expect it's largely "the mod should have contained an impl and now does not anymore"?
I don't see how silencing ambiguity is enough for that. THis can also result in trait selection errors or type mismatches due to incorrect inference
I think that if the set of applicable impls is unknown, trait solving as a whole is somewhat undesirable
|
An alternative is to rely on I agree that the ways that these kind of errors can blow up is myriad. This was an attempt of addressing the reported case without making any claims about other cases that should also be handled. An alternative to this would be to inject a synthetic item into every mod that had parse errors, and look for that item later on when constructing errors... Note that trait selection mismatches due to inference can only happen if this misparsed mod with missing items is part of the currently available search paths... while the current PR is global in its behavior. |
this doesn't seem right. The trait solver is always able to use all trait implementations. I personally feel a lot better about fatally erroring here than inconsistently silencing errors.
This would require tainting the set of trait impls for all traits which are nameable in that module as we e.g. don't know whether any macro in the module would expand to something referencing the trait. This is a lot of complexity for imo fairly limited benefits |
Even in the face of parse recovery of a
mod, when encountering parse errors silence knock-down inference errors.For context, in the repro project from #105618 with a single parse error goes from emitting 69 diagnostics to 1.
Fix #105618.