forked from chapel-lang/chapel
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adjust uAST serializer to store children after subclass fields (chape…
…l-lang#23708) Continuation of PR #chapel-lang#23697. This PR adjusts the uAST serializer/deserializers to store the children after the subclass fields implementing a uAST node. Storing the children after the subclass fields is important to preserve the property that each uAST node is contiguous (other than its children). In my view, that is important for the file format to be possible for a person to debug. However, the way that the `serialize` functions were implemented prevented this reordering because 1) `serialize` was the public interface into these and 2) the only chance `AstNode` has to serialize the children is in `AstNode::serialize` and that's necessarily called before serializing the fields of a subclass. To address that, this PR changes the strategy to differentiate between methods a subclass must provide and the methods for the public interface: * `AstNode::serialize` and `AstNode::deserialize` form the public interface * subclasses need to override `serializeInner(Serializer& ser)` and implement a constructor like `SubClass(Deserializer& des)` * `AstNode::serialize` calls `serializeInner` at the appropriate time. Similarly, `AstNode::deserialize` calls the constructor and deserializes the children at an appropriate time. While there, I noticed that we can remove `DECLARE_STATIC_DESERIALIZE` by having `AstNode::deserialize` simply call `new NAME(des)` for each subclass (according to the tag). Also, since this constructor should not be part of the public API, I enabled it to be `private` / `protected` by making each uAST subclass include `friend class AstNode`. That reduces some of the switching between `public:` and `private:` in these uAST class definitions which appeared in PR chapel-lang#23697. This PR also changes the abstract uAST types to include their name in the method to be called by subclasses in `serializeInner`: e.g., `declSerializeInner`. This matches the pattern already used in `contentsMatchInner` / `markUniqueStringsInner` with e.g. `declContentsMatchInner` / `declMarkUniqueStringsInner`. While I think it's important that these 3 use a consistent style, an alternative would be to use the `::` form in all 3: e.g., `Decl::serializeInner` / `Decl::contentsMatchInner` / `Decl::markUniqueStringsInner`. Additionally, this PR updates the deserializing constructors to use `explicit` to avoid implicit conversion from a deserializer. Lastly, this PR adds a C++ test of the uAST serialization and deserialization. This adds to the existing testing in `test/separate_compilation/serialization`. Reviewed by @benharsh - thanks! - [x] full comm=none testing
- Loading branch information
Showing
100 changed files
with
669 additions
and
701 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.