Bug #10264
Constructors do not support Enum arguments/parameters
100%
History
#1 Updated by Paul Bodale about 1 year ago
- Subject changed from Methods & constructors do not support Enum arguments/parameters to Constructors do not support Enum arguments/parameters
Take the following case:
ENUM task.E:
DEFINE ENUM a
b
c
d.
END ENUM.
CLASS task.A:
CONSTRUCTOR PUBLIC A ( e AS task.E ):
MESSAGE STRING(e).
END CONSTRUCTOR.
END CLASS.
The following program fails at runtime:
DEFINE VARIABLE a AS CLASS task.A. a = NEW task.A (task.E:a). // FWD throws "Ambiguous runtime method call. Could not resolve A reference. (13844)" Error
#4 Updated by Paul Bodale about 1 year ago
- Status changed from New to WIP
- % Done changed from 0 to 90
- reviewer Constantin Asofiei added
I committed rev. 16029 on branch 10264a that introduces a fix for this issue.
This problem could probably be resolved in multiple ways but I choose to do the following:
=== modified file 'src/com/goldencode/p2j/util/ControlFlowOps.java'
--- old/src/com/goldencode/p2j/util/ControlFlowOps.java 2025-06-03 06:47:27 +0000
+++ new/src/com/goldencode/p2j/util/ControlFlowOps.java 2025-07-08 07:39:46 +0000
@@ -5654,6 +5654,11 @@
sigType = r.getType();
arg = r.resolve();
}
+
+ if (arg instanceof EnumObject<?>)
+ {
+ sigType = object.class;
+ }
if (mtypes != null && mtypes[i] == sigType && object.class != sigType)
{
@@ -6402,6 +6407,10 @@
// resolve the super-class type for this constant.
sigType = sigType.getSuperclass();
}
+ else if (arg instanceof EnumObject<?>)
+ {
+ sigType = object.class;
+ }
if (unknown.class == sigType)
{
I modified the ControlFlowOps.resolveLegacyEntry method to allow for EnumObject type instances to be considered of object type to allow them to match correctly. As per the official documentation found here, enums are implicitly class based. This means that they are closely related to classes and can be used in many of the same ways you can use a class type or instance so it's probably better for the implementation to be this way.
#5 Updated by Constantin Asofiei about 1 year ago
Why isn't the change in calculateType enough?
#6 Updated by Paul Bodale about 1 year ago
- % Done changed from 90 to 100
- Status changed from WIP to Review
Constantin Asofiei wrote:
Why isn't the change in
calculateTypeenough?
It is. Sorry, I left it behind from a previous test 🙈
Committed rev. 16030 on branch 10264a.
#7 Updated by Constantin Asofiei about 1 year ago
- Assignee set to Paul Bodale
Please add history entry and move the condition after the ObjectVar check.
#8 Updated by Paul Bodale about 1 year ago
Constantin Asofiei wrote:
Please add history entry and move the condition after the
ObjectVarcheck.
Committed rev. 16032 that addresses this feedback.
#9 Updated by Constantin Asofiei about 1 year ago
- Status changed from Review to Merge Pending
Please merge to trunk now.
#10 Updated by Paul Bodale about 1 year ago
- Status changed from Merge Pending to Test
Branch 10264a was merged into trunk as rev. 16029 and archived.
#11 Updated by Constantin Asofiei 6 months ago
- Status changed from Test to Closed