Stream: t-compiler

Topic: Fatal error during lowering


marmeladema (May 16 2020 at 15:55, on Zulip):

Hello everyone! I have a question about lowering. In order to fix https://github.com/rust-lang/rust/issues/71104 i would like to generate a fatal error for async generator here https://github.com/rust-lang/rust/blob/master/src/librustc_ast_lowering/expr.rs#L1021 instead of letting the compilation continue because the produced hir is invalid

marmeladema (May 16 2020 at 15:55, on Zulip):

Is that a sensible idea?

marmeladema (May 16 2020 at 15:59, on Zulip):

If so, how would I do that?

oli (May 16 2020 at 15:59, on Zulip):

We're trying to remove fatal errors from the compiler. Maybe we can instead create typecktables for these HirNode::Err that have their tainted_by_errors field set: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TypeckTables.html#structfield.tainted_by_errors

oli (May 16 2020 at 16:00, on Zulip):

I think we should explore some other avenues before introducing a new fatal error

marmeladema (May 16 2020 at 16:03, on Zulip):

Ok duly noted. That was just an idea I had. It was to clean up this FIXME i added: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/ty/context.rs#L1117

marmeladema (May 16 2020 at 16:04, on Zulip):

Maybe one improvements could be to not store NodeId in resolutions.trait_map? Instead storing DefId or NodeId?

oli (May 16 2020 at 16:05, on Zulip):

sorry, this is severely out of my mental cache, I need to read up and I don't have that time at the moment. Feel free to ping me on monday if you still don't have an answer

marmeladema (May 16 2020 at 16:06, on Zulip):

Sure! I'll investigate a bit.

marmeladema (May 16 2020 at 17:31, on Zulip):

So instead of generating a fatal error, we can just avoid returning a hir::ExprKind::Err and keep going with the lowering: https://github.com/rust-lang/rust/pull/72275

Last update: Jun 04 2020 at 16:35UTC