[code-reflection] RFR: 8324556: Not copy result-type when copying an op [v5]

[Maurizio Cimadamore]

On Thu, 1 Feb 2024 00:47:38 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> 8324556: Not copy result-type when copying an op
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into not-copy-resultType-when-copying-op
>  - Add documentation
>  - Remove validation from resultType method
>  - Review
>  - Add test
>  - Apply Paul's suggestions
>  - Not copy resultType when copying an op.

Late to the party - I'm a bit worried about this fix. For instance, the `resultType` of a binary op seems to be the type of its first operand. I believe that, if we're in the business of computing op types automatically, based on the input types of their operands, then the rules we use should adhere to the ones in the Java Language Specification. This can have issues when it comes to the compiler code, I think - as for javac, `+(Integer, int)` has type `int`, but the Op for that binary expression would have an Integer descriptor. This means that we introduce a discrepancy between the type javac thinks an expression has, and the type of the `op` modelling that expression.

Why this works, I think, is that we rely on javac to have converted all the input ops to the right type _before_ applying a binary operator. That is, javac will unbox any Integer operand to int, and then use the int operands for the binary operation. This means `CoreOps::AddOp` can pick whatever operand type as the result type, and everything will be correct. But this is only true for IRs generated by javac! If there is a wider constrain on the fact that "binary operations should have operands that are all of the same type" and "the type must better be a primitive", then I think such constraints ought to be enforced at the API level (so that constructing a binary operation with "bad" operands is not possible).

I think a similar discussion also applies to ternary expression and switch expressions - but I see that, in those cases, the factories for the corresponding ops still accept a result type parameter.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/6#issuecomment-1921181768