| Age | Commit message (Collapse) | Author |
|
Because it ends up treating it as a local variable, and `a.x`
is not a valid local variable name.
I'm not big on pattern matching, but conceptually it makes sense to me
to treat anything inside ^() to not be
pattern matching syntax?
https://github.com/ruby/prism/commit/80dbd85c45
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13017
|
|
mutable dependencies array
That restores support for compact index dummy implementations that only lists
versions, without checksums or dependencies.
This format is undocumented, so we may want to get rid of it in the
future. However, some of our tests rely on it, and some implementations
did use it (gems.mutant.dev at least). And the way the code was written
suggest that support was intentional.
So for now, we should restore it.
https://github.com/rubygems/rubygems/commit/0427d8c983
|
|
It's available in RubyGems since 3.2.3 and we no longer support that old
version.
|
|
https://github.com/rubygems/rubygems/commit/792117980b
|
|
have changed
Since we will now add it back if the final resolution is compatible, we
can also get this kind of edge case (`bundle add`) working.
https://github.com/rubygems/rubygems/commit/cdc5ebec77
|
|
Instead, remove them anytime we find dependencies don't match the
lockfile for a platform, and then add them back after resolution if
they ended up being valid.
https://github.com/rubygems/rubygems/commit/220bd77887
|
|
anything
https://github.com/rubygems/rubygems/commit/9fd92ade54
|
|
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
|
|
|