prism 2.0.0.rc1-x86_64-linux-gnu → 2.0.0-x86_64-linux-gnu

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: cc11883eb4ab950f920cf9fafa80b2edde172ccffd5c3ddd485f3f785206b370
-  data.tar.gz: 7e460ef605ed206d9ba12247ece6240d272f24e5a080e2df6a46fb9adfa4e1cb
+  metadata.gz: d049e300ef2d9c5af5bd441bbadbcdff214d807763871245df453fc7ff19a1f7
+  data.tar.gz: 0add7f7ee8b9d36545edf64fd6dcbb8ec807d9f2538775c7e03b0bf1168c4421
 SHA512:
-  metadata.gz: 57d4a9a445c1abce8ddd30f7b8e53d0e5bb46742c08ab44a2309b672e1afb3ad9144de4f583abe6caa653370168d993aaf29ac5615003984c874dfef943ce4dd
-  data.tar.gz: c12fce41b7fab93c320288a6011044744b7a460f2cef6eb61d221589a1afe849658ae5272cb187067a3741d137ac26cfa6003292e2a98f2bce85ade802712e9b
+  metadata.gz: 48411e04db366ce83feef1f3dbff740178d47087b3712ec97b8d1cfd131ee19108d93fc1f8ee1fea3fffa0771cfb948b9d5e822a02bd5c6a0ed2bd216674d867
+  data.tar.gz: b6f406a99be3901c67bfc7c38476d164db22c17610190f5edb9c4a7e5a125c5dfa1eac294bba1b3a8a1d10064f1386bdf7e2da4329328b932731a1702722e5ba

data/CHANGELOG.md

@@ -6,12 +6,16 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) a
 
 ## [Unreleased]
 
+## [2.0.0] - 2026-10-21
+
 ### Highlights
 
 - Significant performance and memory usage improvements.
 - Precompiled platform-specific variants on rubygems.org.
 - Many documentation improvements, including a new playground.
 - Prism now ships accurate and complete RBS and RBI definitions.
+- The license is now owned by the Ruby developers.
+- Prism now ships an official C++ interface.
 
 ### Added
 
@@ -29,6 +33,8 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) a
 - Allow pattern matching with prism nodes to match on location slices, like `node in Prism::StringNode[content: "foo"]`.
 - `Prism.parse_file` and similar now accept anything responding to `to_path` (like `Pathname`) directly.
 - `attach_comments` was added as a valid option. Each comment is attached to the node that ends latest on the comment's line before it, otherwise to the innermost node that contains it (or to that node's statements, if only whitespace and comments come between the comment and the statements), otherwise to the top-level statements. The attached comments are available through `Node#comments` and through `pm_node_comments_size` and `pm_node_comment` in the C API, as well as `pm_parser_comment_attachment`, `pm_parser_comment_ranges_size`, and `pm_parser_comment_range`, which expose the attachments grouped by node. When the option is set, the comments on the parse result are sorted by start offset.
+- `StringQuery#keyword?` was added to check if the string query matches a keyword.
+- `Source#checksum` was added to retrieve the checksum of the source content.
 
 ### Changed
 
@@ -64,6 +70,9 @@ Note that for this major version, almost every change listed below is breaking.
 - Most allocations are now performed through an arena.
 - You may now build side tables of comment attachments through the `attach_comments` option.
 - `newline_list` was renamed to `list_offset_list`.
+- Visitor callbacks passed to `pm_visit_node` and `pm_visit_child_nodes` now return a `pm_visit_result_t` instead of a `bool`. Returning `PM_VISIT_DESCEND` or `PM_VISIT_SKIP` replaces returning `true` or `false`, and returning `PM_VISIT_STOP` ends the walk. Both functions now return `false` if the walk was stopped.
+- `pm_string_t` is now a view of bytes owned by someone else. It no longer has a `type` field, `pm_string_owned_init` was removed, and `pm_string_constant_init` was renamed to `pm_string_init`, which takes the bytes as `const uint8_t *`.
+- `pm_options_free` no longer frees the names of scope locals. The parser copies them when it is created, so they only need to remain valid until then.
 
 #### Rust
 
@@ -71,6 +80,7 @@ Note that for this major version, almost every change listed below is breaking.
 - Most allocations are now performed through an arena.
 - `newline_list` was renamed to `list_offset_list`.
 - `Diagnostic::message` now returns `&[u8]` instead of `&str`.
+- `StringQuery` is now exposed.
 
 #### JavaScript
 
@@ -827,8 +837,9 @@ Note that for this major version, almost every change listed below is breaking.
 
 - 🎉 Initial release! 🎉
 
-[unreleased]: https://github.com/ruby/prism/compare/v1.9.0...HEAD
-[1.9.0]: https://github.com/ruby/prism/compare/v1.8.0...v1.9.0
+[unreleased]: https://github.com/ruby/prism/compare/v2.0.0...HEAD
+[2.0.0]: https://github.com/ruby/prism/compare/v1.9.0...v2.0.0
+[1.9.0]: https://github.com/ruby/prism/compare/v1.8.1...v1.9.0
 [1.8.1]: https://github.com/ruby/prism/compare/v1.8.0...v1.8.1
 [1.8.0]: https://github.com/ruby/prism/compare/v1.7.0...v1.8.0
 [1.7.0]: https://github.com/ruby/prism/compare/v1.6.0...v1.7.0

data/CODE_OF_CONDUCT.md

@@ -55,7 +55,7 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at opensource@shopify.com. All
+reported by contacting the project team at ruby-core@ruby-lang.org. All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
 obligated to maintain confidentiality with regard to the reporter of an incident.

data/LICENSE.md

@@ -1,4 +1,4 @@
-Copyright 2022-present, Shopify Inc.
+Copyright 2022-present, Ruby developers
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
 

data/docs/serialization.md

@@ -106,6 +106,7 @@ The header is structured like the following table:
 | `1` | 1 indicates only semantics fields were serialized, 0 indicates all fields were serialized (including location fields) |
 | string | the encoding name |
 | varsint | the start line |
+| `8` | the checksum of the source up to the end of the `__END__` line in native endian order, see `pm_parser_checksum` |
 | varuint | number of newline offsets |
 | varuint* | newline offsets |
 | varuint | number of comments |
@@ -124,8 +125,14 @@ The header is structured like the following table:
 | varuint | content pool size |
 
 After the header comes the body of the serialized string.
-The body consists of a sequence of nodes that is built using a prefix traversal order of the syntax tree.
-Each node is structured like the following table:
+The body consists of a sequence of nodes that is built using a postfix traversal order of the syntax tree: the children of each node come before the node itself, so the root node comes last.
+The body ends at the content pool offset specified in the header.
+
+The children of a node are the values of its `node`, `node?`, and `node[]` fields, which are serialized in the order in which the fields are listed in `config.yml`.
+A `node` field is serialized as its node, a `node?` field is serialized as its node or as a single `0` byte if the node is not present, and a `node[]` field is serialized as each of its nodes in order.
+A loader can therefore keep a stack of loaded nodes: a `0` byte pushes an absent node, and each node pops its children off the top of the stack (they are in field order) and then pushes itself.
+
+After its children, each node is structured like the following table:
 
 | # bytes | field |
 | --- | --- |
@@ -134,12 +141,11 @@ Each node is structured like the following table:
 | location | node location |
 | varuint | node flags |
 
-Every field on the node is then appended to the serialized string. The fields can be determined by referencing `config.yml`. Depending on the type of field, it could take a couple of different forms, described below:
+Every other field on the node is then appended to the serialized string. The fields can be determined by referencing `config.yml`. Depending on the type of field, it could take a couple of different forms, described below:
 
 * `double` - A field that is a `double`. This is structured as a sequence of 8 bytes in native endian order.
-* `node` - A field that is a node. This is structured just as like parent node.
-* `node?` - A field that is a node that is optionally present. If the node is not present, then a single `0` byte will be written in its place. If it is present, then it will be structured just as like parent node.
-* `node[]` - A field that is an array of nodes. This is structured as a variable-length integer length, followed by the child nodes themselves.
+* `node`, `node?` - Nothing is appended here, since the node has already been serialized as a child.
+* `node[]` - A field that is an array of nodes. This is structured as a variable-length integer length, which is the number of children that belong to this field.
 * `string` - A field that is a string. For example, this is used as the name of the method in a call node, since it cannot directly reference the source string (as in `@-` or `foo=`). This is structured as a variable-length integer byte length, followed by the string bytes (_without_ a trailing null byte).
 * `constant` - A variable-length integer that represents an index in the constant pool.
 * `constant?` - An optional variable-length integer that represents an index in the constant pool. If it's not present, then a single `0` byte will be written in its place.
@@ -149,6 +155,14 @@ Every field on the node is then appended to the serialized string. The fields ca
 * `uint8` - A field that is an 8-bit unsigned integer. This is structured as a single byte.
 * `uint32` - A field that is a 32-bit unsigned integer. This is structured as a variable-length integer.
 
+The `body` field of a `DefNode` is lazy, which means that loaders can skip it and load it later. The children of a `DefNode` are preceded by the following, which loaders that do not skip lazy fields can ignore:
+
+| # bytes | field |
+| --- | --- |
+| `1` | `255` |
+| `4` | the byte length of the children that come before the `body` child |
+| `4` | the byte length of the `body` child |
+
 After the syntax tree, the content pool is serialized. This is a list of constants that were referenced from within the tree. The content pool begins at the offset specified in the header. Every constant is embedded in the serialization. Each constant is structured as follows:
 
 | # bytes | field |