GP-296 avoid separately resolving nested composite definitions to avoid

duplicates.  Allow them to be resolved as needed (e.g., function
definitions).
This commit is contained in:
ghidra1 2020-10-21 14:44:58 -04:00
parent 3791d9d5d1
commit 0086c4c77a
2 changed files with 13 additions and 1 deletions

View file

@ -59,6 +59,10 @@ public abstract class AbstractComplexTypeApplier extends MsTypeApplier {
return ((AbstractComplexMsType) msType).getMsProperty().isForwardReference();
}
boolean isNested() {
return ((AbstractComplexMsType) msType).getMsProperty().isNestedClass();
}
boolean isFinal() {
return ((AbstractComplexMsType) msType).getMsProperty().isSealed();
}

View file

@ -135,7 +135,15 @@ public class CompositeTypeApplier extends AbstractComplexTypeApplier {
@Override
void resolve() {
if (!isForwardReference()) {
// NOTE: Until we know better we do not want to explicitly
// apply nested composite datatypes and allow them to be
// created as-needed (e.g., function definition). This is
// done to minimize duplication of anonymous/unnamed nested
// composites since the parent composite reconsruction performed
// by DefaultCompisiteMember will generate such nested composites.
if (!isForwardReference() && !isNested()) {
super.resolve();
}
}