Skip to content

ExpressionBuilder: add "Adjustments" - #4281

Open
dgrunwald wants to merge 7 commits into
masterfrom
adjustment
Open

dgrunwald wants to merge 7 commits into
masterfrom
adjustment

Conversation

@dgrunwald

Copy link
Copy Markdown
Member

The ExpressionBuilder previously had a complex post-condition: an ILInstruction with StackType.I (nint) could actually be translated into a C# expression with type int or long, as long as after a cast to nint the value would match that computed by the original instruction.
This PR introduces the idea of calling this mismatch between C# and ILAst semantics an "adjustment", and represents it explicitly within TranslatedExpression.
This comes with a new set of methods on TranslatedExpression that effectively abstract over the (C# expression + adjustment) combination -- for example adding additional casts on top of it (merging those casts with the existing adjustment when possible).

This initial PR introduces the idea and uses it in VisitConv.
Next steps (in follow-up PRs):

  • switch over more of the ExpressionBuilder from the old API to the new API
  • remove old APIs -- especially the implicit conversion from TranslatedExpression to Expression, as this just returns the unadjusted expression and easily causes bugs when the adjustment is not considered
  • remove ConvertTo -- this method could do many kinds of conversions and in some edge cases it could be unclear what kind of conversion it would be doing. It will be replaced by multiple more focused methods.
  • After all ExpressionBuilder.Visit* functions are migrated to this new API, it will be possible to introduce more kinds of adjustments -- for example, boxing conversions. All cases where ConvertTo(allowImplicit: true) currently removes cast expressions will be turned into adjustments.
  • After that it will be possible to use adjustments for new features, especially stuff related to target-typing ([] list literals etc.).

/// * Using the unadjusted expression in any other context is not possible (might be invalid C#,
/// might have incorrect semantics).
/// * for other AdjustmentKind values:
/// *

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

incomplete?

…e difference between the translated C# expression and the original IL instruction.

The idea here is that we allow refactoring the expression builder method-by-method: legacy Visit* overloads can continue returning according to the old post-condition and Translate() will inject the necessary adjustments.

Includes a bugfix where `binary.sub.ref(a, b)` (as in Unsafe.ByteOffset) was interpreted to have return type `Ref`, when it should be `I`.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants