summaryrefslogtreecommitdiffstats
path: root/tests
diff options
context:
space:
mode:
authorTheresa Foley <10618364+tangent-vector@users.noreply.github.com>2025-04-29 18:00:04 -0700
committerGitHub <noreply@github.com>2025-04-29 18:00:04 -0700
commit41ac7a0d8b4e9c08eccc2153020900e0262cae84 (patch)
tree72983851049ef4ace01b14c1a539c8424f282c61 /tests
parentb02771f235909fb9399bd3969dbea0d4115ae016 (diff)
Fixes related to AST serialization change (#6953)
* Fixes related to AST serialization change There are two fixes included here. The smaller fix is in `slang-ast-decl.h`, where the `CallableDecl::primaryDecl` and `::nextDecl` fields need to be serialized to make sure that we can properly deserialize a module that contains any function redeclarations. The larger fix is that the `Encoder` and `Decoder` types used to serialize out the AST nodes in a JSON-like hierarchy were being very strict about matching of integer types, which causes problems in any case where serialization code might use a type that is 32-bit on some targets and 64-bit on others, if serialized modules are ever created on one of those targets and consumed on the other (which happens for the core module for some of our targets). The fix that this change implements is to make the serialization logic there more forgiving, and thus more robust: * In the writing/encoding direction, the logic now looks at the actual value being encoded to decide whether to write it as a 32- or 64-bit value. * In the reading/decoding direction, the logic handles the presence of *any* of the FOURCCs that are used to encode integers, for whatever type is being read. As a small bit of safety, there is a dynamic check made for cases where a value would be read with a different sign than it was written with. The actual logic in `slang-serialize-ast.cpp` is largely unchanged (it continues to use pointer-sized integers in certain cases), but it should not cause problems because it bottlenecks through the `Encoder`/`Decoder` methods that were changed. The only fix made in the AST serialization itself is to account for all of the FOURCCs that can represent integers when peeking at the input to decide whether a `DeclBase` is represented as an indirection to a `Decl`, or is serialized inline (as a `DeclGroup`). * format code --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions