Continue compilation even if inherent impl checks fail by oli-obk · Pull Request #121113 · rust-lang/rust (original) (raw)
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#130764 - compiler-errors:inherent, r=estebank
Separate collection of crate-local inherent impls from error tracking
rust-lang#119895 changed the return type of the crate_inherent_impls query from CrateInherentImpls to Result<CrateInherentImpls, ErrorGuaranteed> to avoid needing to use the non-parallel-friendly track_errors() to track if an error was reporting from within the query... This was mostly fine until rust-lang#121113, which stopped halting compilation when we hit an Err(ErrorGuaranteed) in the crate_inherent_impls query.
Thus we proceed onwards to typeck, and since a return type of Result<CrateInherentImpls, ErrorGuaranteed> means that the query can either return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any Err(ErrorGuaranteed) return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in rust-lang#127798.
This PR changes the crate_inherent_impls query to return (CrateInherentImpls, Result<(), ErrorGuaranteed>), i.e. returning the inherent impls collected and whether an error was reported in the query itself. It firewalls the latter part of that query into a new crate_inherent_impls_validity_check just for the ensure() call.
This fixes rust-lang#127798.