Issue created by jeff-aion (on Tuesday Nov 06, 2018 at 22:10 GMT)
The HeapMemoryCostCalculator is consulted before we run the RejectionClassVisitor so it possible that an invalid superclass can be referenced from user code. This will cause us to fail to find the instance size for that class, thus throwing an exception in the DAppCreator.
We could change the HeapMemoryCostCalculator to know that such failures should be interpreted as RejectedClassException but this is mixing responsibilities and is likely just the tip of the iceberg related to such pre-rejection decision exceptions.
Instead, we will move the RejectionClassVisitor and UserClassMappingVisitor out into a pre-pass where this static rejection and renaming can be done, meaning that the later 2 transformation pipelines can always assume that the classes are obeying all the rules and are in the appropriately renamed shape.
Issue created by jeff-aion (on Tuesday Nov 06, 2018 at 22:10 GMT)
The
HeapMemoryCostCalculatoris consulted before we run theRejectionClassVisitorso it possible that an invalid superclass can be referenced from user code. This will cause us to fail to find the instance size for that class, thus throwing an exception in theDAppCreator.We could change the
HeapMemoryCostCalculatorto know that such failures should be interpreted asRejectedClassExceptionbut this is mixing responsibilities and is likely just the tip of the iceberg related to such pre-rejection decision exceptions.Instead, we will move the
RejectionClassVisitorandUserClassMappingVisitorout into a pre-pass where this static rejection and renaming can be done, meaning that the later 2 transformation pipelines can always assume that the classes are obeying all the rules and are in the appropriately renamed shape.