Rust-GCC
nr2.0: Run a final `TopLevel` pass after desugaring
I don't know if this is the best way to go about this, it's definitely hacky. maybe we could do all the desugars as part of the fixed point and mark the visitor as dirty when we find something to desugar
I don't know if this is the best way to go about this, it's definitely hacky. maybe we could do all the desugars as part of the fixed point and mark the visitor as dirty when we find something to desugar
It looks like doing exactly that would screw up recursion_limit tracking -- I've reworked the patch to put desugaring + the final TopLevel pass in the fixed point loop though, which seems a bit less hacky.
I don't know if this is the best way to go about this, it's definitely hacky. maybe we could do all the desugars as part of the fixed point and mark the visitor as dirty when we find something to desugar
It looks like doing exactly that would screw up
recursion_limittracking -- I've reworked the patch to put desugaring + the finalTopLevelpass in the fixed point loop though, which seems a bit less hacky.
It looks like this doesn't work, as the desugaring doesn't seem to handle partially complete early resolution well. I have moved the desugaring and last TopLevel pass to the expansion function, though.
It looks like doing exactly that would screw up recursion_limit tracking
how do you mean? desugaring shouldn't count for the expansion limit, as we control the expansion (as opposed to a user-defined macro).
It looks like doing exactly that would screw up recursion_limit tracking
how do you mean? desugaring shouldn't count for the expansion limit, as we control the expansion (as opposed to a user-defined macro).
The fixed point loop would either have to skip desugaring if we hit the expansion limit or run an extra iteration past the expansion limit.
I think this is not really an issue, if we hit the expansion limit we'll have an error anyway and will stop the pipeline. so the desugaring does not matter. I think the resulting code would be more correct
I think this is not really an issue, if we hit the expansion limit we'll have an error anyway and will stop the pipeline. so the desugaring does not matter. I think the resulting code would be more correct
I'm having trouble writing code that both includes desugaring in the main loop and that I can verify doesn't introduce an off-by-one error to cfg.recursion_limit. I've pushed what I have so far -- it looks correct, but I'm not sure its better than what I had before.