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 i would like to generate a fatal error for async generator here 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:

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:

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:

Last update: Jun 04 2020 at 16:35UTC