We don't consider indented expressions that are normal expressions, only those that are expressionized statements. So x =\n if ... is considered an indented expression, but x =\n y isn't. I think this is broken.
Basically, I added a few MaybeNested...Expressions that check for a properly indented expression. And I reviewed all uses of ExtendedExpression and a few others and decided whether to add this prefix. Mostly right-hand sides of assignments get this new treatment.
However, because we fallback to not-properly-nested parsing, it's still the case that a =\n x\n yparses as a function call. As a result of this, I can't actually think up a situation where this PR affects compilation. But it makes me feel more confident that PushIndent will have the correct indentation in some future situations... but given that it doesn't matter yet, it's also plausible that this part of the PR should wait. What do you think? (Alternatively, we could try to be stricter: when the expression starts FurtherIndented, it must be properly nested. I'm not sure whether this would work well in practice though... we're maybe used to having weirdly (non)indented expressions.)
Also added missing feature of throwing a nested expression, using the (existing but renamed) MaybeParenNestedExtendedExpression. This parallels existing features for return and yield.
Also renamed MaybeIndentedType to MaybeNestedType for consistency.
Follow up to https://github.com/DanielXMoore/Civet/pull/1293#issue-2372895605
Basically, I added a few
MaybeNested...Expressions that check for a properly indented expression. And I reviewed all uses ofExtendedExpressionand a few others and decided whether to add this prefix. Mostly right-hand sides of assignments get this new treatment.However, because we fallback to not-properly-nested parsing, it's still the case that
a =\n x\n yparses as a function call. As a result of this, I can't actually think up a situation where this PR affects compilation. But it makes me feel more confident thatPushIndentwill have the correct indentation in some future situations... but given that it doesn't matter yet, it's also plausible that this part of the PR should wait. What do you think? (Alternatively, we could try to be stricter: when the expression startsFurtherIndented, it must be properly nested. I'm not sure whether this would work well in practice though... we're maybe used to having weirdly (non)indented expressions.)Also added missing feature of
throwing a nested expression, using the (existing but renamed)MaybeParenNestedExtendedExpression. This parallels existing features forreturnandyield.Also renamed
MaybeIndentedTypetoMaybeNestedTypefor consistency.