nac3core: Add field "constructor_lookup" to the struct TopLevelComposer #308
No reviewers
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/nac3#308
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "issue-139"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The code below failed because the InnerResolver's 'pyid_to_type' table didn't store the type information for the classes that don't have their own constructor.
In the register step, TopLevelComposer::reigster_top_level won't return the constructor's type of the class that doesn't have a constructor and therefore the 'pyid_to_type' will not be abled to store the type information for the class (the ty is None here).
This change add a field 'constructor_lookup' (HashMap) to TopLevelComposer which maintain a mapping between class name to constructor function definition.
With the 'constructor_lookup' table, the TopLevelComposer::reigster_top_level will be able to recognize and return the constructor's type for classes that inherit constructor function from its base class and 'pyid_to_type' will store the type information for the class as a result.
@ -37,6 +37,8 @@ pub struct TopLevelComposer {
// number of built-in function and classes in the definition list, later skip
pub builtin_num: usize,
pub core_config: ComposerConfig,
// the class name and it's constructor function
its
It is not clear from your description whether this fixes issue #139 or not.
Why do constructors need such special treatment compared to other inherited methods?
Pull request closed