| Age | Commit message (Collapse) | Author |
|---|
| I don't like traversing the array and modifying it at the same time while it seems to work. https://github.com/rubygems/rubygems/commit/6551c74c27 |
| `StringNode` and `SymbolNode` don't have the same shape (`content` vs `value`) and that wasn't handled. I believe the logic for the common case can be reused. I simply left the special handling for implicit nodes in pattern matching and fall through otherwise. NOTE: patterns.txt is not actually tested at the moment, because it contains syntax that `parser` mistakenly rejects. But I checked manually that this doesn't introduce other failures. https://github.com/whitequark/parser/pull/1060 https://github.com/ruby/prism/commit/55adfaa895 |
| [Bug #21197] https://github.com/ruby/prism/commit/22be955ce9 Notes: Merged: https://github.com/ruby/ruby/pull/12999 |
| https://github.com/rubygems/rubygems/commit/33c3caa63f |
| https://github.com/rubygems/rubygems/commit/4bbf02493e |
| https://github.com/rubygems/rubygems/commit/01a14a7073 |
| My application spends more than 30% of time during `bundle update` comparing versions due to versions being sorted inside next_package_to_try. This has been addressed in pub_grub by defining a strategy interface (a `#next_package_and_version` method) which allows consumers to have finer control over the heuristic to select the next package to try. This commit implements the new strategy interface to remove extraneous version sorting (previously in next_package_to_try) since only the final count of versions is used. Combined with a previous change to pub_grub (already applied to Bundler), this commit results in `bundle update` taking only half the time it did on 2.6.5. https://github.com/rubygems/rubygems/commit/62f69e27f0 |
| This decouples `gem exec` behavior (and tests) from the sort order of the gemspec. https://github.com/rubygems/rubygems/commit/911cd29159 |
| https://github.com/rubygems/rubygems/commit/a0f7851451 |
| https://github.com/rubygems/rubygems/commit/4497555023 |
| missing https://github.com/rubygems/rubygems/commit/054a0cd76c Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| It's a dependency, not a specification. https://github.com/rubygems/rubygems/commit/9d78f5aa14 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| with checksums https://github.com/rubygems/rubygems/commit/8e2c5748d9 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| Instead of doing an explicit pass, let sources be replaced while checking if specifications are up to date. https://github.com/rubygems/rubygems/commit/676271e804 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| Instead of doing an explicit pass to preserve the source from the Gemfile when it's a `Source::Gemspec`, add a special case to our generic source replacement method. https://github.com/rubygems/rubygems/commit/20c8c42380 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| sources The `converge_dependencies` method already replaces the source of the dependency with an equivalent source from the Gemfile if possible. https://github.com/rubygems/rubygems/commit/a449e7ba19 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/58e9bd9962 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/4c05ac8306 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/24523a839e Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/9c6b57c01d Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/e9f4d1e5c2 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/7026b5f2e5 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/4e66fe4208 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| One error message that we parse is now slightly different. https://github.com/rubygems/rubygems/commit/758528791d Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| reproducible builds. https://github.com/rubygems/rubygems/commit/1d5a627398 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| When `gem exec foo` is run, and "foo" is a gem that has multiple executables, none of them named "foo", raise an error explaining the situation and telling user to be more specific. Currently the first command in the executables array is run, but this may come as surprising sometimes, so better raise an error. https://github.com/rubygems/rubygems/commit/acda5d8f6e Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/3aaa75e7b9 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| It reads better this way I think. https://github.com/rubygems/rubygems/commit/ce9743290d Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/558a4765c7 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/rubygems/rubygems/commit/e891be9197 Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| It meant to mention the lockfile here. https://github.com/rubygems/rubygems/commit/2f0233a0fb Notes: Merged: https://github.com/ruby/ruby/pull/12968 |
| https://github.com/ruby/prism/commit/594e2a69ed |
| There hasn't been much that would actually affect parsers usage of it. But, when adding new node types, these usually appear in the `Parser::Meta::NODE_TYPES`. `itblock` was added, gets emitted by prism, and then `rubocop-ast` blindly delegates to `on_itblock`. These methods are dynamically created through `NODE_TYPES`, which means that it will error if it doesn't contain `itblock`. This is unfortunate because in `rubocop-ast` these methods are eagerly defined but the prism translator is lazily loaded on demand. The simplest solution is to add them on the `parser` side (even if they are not emitted directly), and require that a version that contains those be used. In summary when adding a new node type: * Add it to `Parser::Meta::PRISM_TRANSLATION_PARSER_NODE_TYPES` (gets included in `NODE_TYPES`) * Bump the minimum `parser` version used by `prism` to a version that contains the above change * Actually emit that node type in `prism` https://github.com/ruby/prism/commit/d73783d065 |
| There will be a bunch of other problems should 3.10 ever exists, but I guess why not fix this one now. https://github.com/ruby/prism/commit/b385f47f8b |
| It's not my favorite api but for users that currently use the same thing from `parser`, moving over is more difficult than it needs to be. If you plan to support both old and new ruby versions, you definitly need to branch somewhere on the ruby version to either choose prism or parser. But with prism you then need to enumerate all the versions again and choose the correct one. Also, don't recommend to use `Prism::Translation::Parser` in docs. It's version-less but actually always just uses Ruby 3.4 which is probably not what the user intended. Note: parser also warns when the patch version doesn't match what it expects. But I don't think prism has such a concept, and anyways it would require releases anytime ruby releases, which I don't think is very desirable https://github.com/ruby/prism/commit/77177f9e92 |
| https://github.com/ruby/prism/commit/c02429765b |
| https://github.com/ruby/prism/commit/d85c72a1b9 |
| `category` is only supported from Ruby 3.0 onwards and prism can still run with Ruyb 2.7 https://github.com/ruby/prism/commit/335a193851 |
| builder class In https://github.com/ruby/prism/pull/3494 I added a bit of code so that using the new builder doesn't break stuff. This code can be dropped when it is enforced that builder is _always_ the correct subclass (and makes future issues like that unlikely). https://github.com/ruby/prism/commit/193d4b806d |
| https://github.com/ruby/optparse/commit/8c2c7a4903 |
| https://github.com/ruby/prism/commit/71d31db496 |
| |
| Caused by https://github.com/ruby/prism/pull/3478 and https://github.com/ruby/prism/pull/3443 I also made the builder reference more explicit to clearly distinquish between `::Parser` and `Prism::Translation::Parser` https://github.com/ruby/prism/commit/d52aaa75b6 |
| ``` (a,), = [] PARSER==================== s(:masgn, s(:mlhs, s(:mlhs, s(:lvasgn, :a))), s(:array)) PRISM==================== s(:masgn, s(:mlhs, s(:lvasgn, :a)), s(:array)) ``` https://github.com/ruby/prism/commit/8aa1f4690e |
| In https://github.com/ruby/prism/commit/26370079291a420c6b2b7be5cdbd5c609da62f21 I added tests but didn't modify them correctly https://github.com/ruby/prism/commit/de021e74de |
| Mostly around newlines and line continuation. * percent arrays need special backslash handling in the ast * Fix offset issue for heredocs with many line continuations (used wrong variable as index access) * More refined rules on when to simplify string tokens * Handle line continuations in squiggly heredocs * Correctly dedent squiggly heredocs with interpolation * Consider `':foo:` and `%s[foo]` to not be interpolation https://github.com/ruby/prism/commit/4edfe9d981 |
| https://github.com/ruby/prism/commit/422d5c4c64 |
| I see `Array.include?` as 2.4% runtime. Probably because of `LPAREN_CONVERSION_TOKEN_TYPES` but the others will be faster as well. Also remove some inline array checks. They are specifically optimized in Ruby since 3.4, but for now prism is for >= 2.7 https://github.com/ruby/prism/commit/ca9500a3fc |
| `Integer#chr` performs some validation that we don't want/need. Octal escapes can go above 255, where it will then raise trying to convert. `append_as_bytes` actually allows to pass a number, so we can just skip that call. Although, on older rubies of course we still need to handle this in the polyfill. I don't really like using `pack` but don't know of another way to do so. For the utf-8 escapes, this is not an issue. Invalid utf-8 in these is simply a syntax error. https://github.com/ruby/prism/commit/161c606b1f |
| https://github.com/ruby/prism/commit/09c59a3aa5 |
