Make P4-Constraints Typechecker Idempotent

[Kaiwen-Guo]

Make P4-Constraints Typechecker Idempotent

Description

This PR addresses issue #140 by making the P4-Constraints typechecker idempotent, allowing it to be called multiple times on the same expression without failing.

Changes

• Added OneLevelAboveInCastabilityOrder function to enforce that type casts only move a single level up in the Hasse diagram
• Modified the kTypeCast case in InferAndCheckTypes to properly validate type casts
• Updated the typechecker to recursively check inner expressions within a type cast
• Added a test to verify idempotent behavior

How to Test

• Added new test IdempotentTypeCastHandling that verifies the typechecker can be called multiple times on the same expression

[Kaiwen-Guo]

Fixed problems with Signed-off-by and formatting

[jameshu15869]

I might be misunderstanding this, but in the case of casting bit<W> (kFixedUnsigned) to exact<W> | ternary<W> | lpm<W> | range<W> | optional<W>, do we need to check that the bit widths match?

e.g. in StrictlyAboveInCastabilityOrder:

switch (left.type_case()) {
    case Type::kExact:
    case Type::kTernary:
    case Type::kLpm:
    case Type::kRange:
    case Type::kOptionalMatch:
      switch (right.type_case()) {
        case Type::kFixedUnsigned:
          return TypeBitwidth(left) == TypeBitwidth(right); <------ bit width check
        case Type::kArbitraryInt:
          return true;
        default:
          return false;
      }

[Kaiwen-Guo]

Yeah that's a great point. I now added additionalTypeBitwidth checks during case 2 return

[jameshu15869]

IIUC, changing InferAndCheckTypes() to be idempotent should cause TypeCastNeverTypeChecks to fail because we are no longer erroring immediately upon encountering a type cast. Based on a quick look it seems to me that the test case Expression expr = ParseTextProtoOrDie<Expression>(R"pb(type_cast { integer_constant: "0" })pb"); is not a valid type cast expression since left is set to TYPE_NOT_SET and right is set to kArbitraryInt when OneLevelAboveInCastabilityOrder() is called, which instantly returns false because TYPE_NOT_SET isn't accounted for in the castability order.

i.e. I think that the test is currently passing because the function returns kInvalidArgument for the wrong reason.

I got the test to fail (In this case return Ok() when an error was expected) using the test case below - let me know if you can reproduce

TEST_F(InferAndCheckTypesTest, TypeCastNeverTypeChecks) {
  Expression expr = ParseTextProtoOrDie<Expression>(R"pb(
    binary_expression {
      binop: EQ
      left {
        type { exact { bitwidth: 32 } }
        key: "exact32"
      }
      right {
        type { exact { bitwidth: 32 } }
        type_cast {
          type { fixed_unsigned { bitwidth: 32 } }
          type_cast {
            type { arbitrary_int {} }
            integer_constant: "48"
          }
        }
      }
    }
  )pb");
  AddMockSourceLocations(expr);
  ASSERT_THAT(InferAndCheckTypes(&expr, kTableInfo),
              StatusIs(StatusCode::kInvalidArgument));
}

[Kaiwen-Guo]

This really depends on whether nested type casts should be allowed. If it should not be allowed, then we can add an additional check after getting the inner expression to raise any corresponding errors:

      if (inner_expr->expression_case() == ast::Expression::kTypeCast) {
        return StaticTypeError(constraint_source, expr->start_location(),
                               expr->end_location())
               << "nested type casts are not allowed";
      }