| Age | Commit message (Collapse) | Author |
|
https://github.com/ruby/prism/commit/e6e17778f8
|
|
https://github.com/ruby/prism/commit/107ffb64a3
|
|
https://github.com/ruby/prism/commit/93d06436f7
|
|
https://github.com/ruby/prism/commit/129ed94cb5
|
|
https://github.com/ruby/prism/commit/b2dc35d902
|
|
https://github.com/ruby/prism/commit/4e64b9fc53
|
|
https://github.com/ruby/prism/commit/57f991a6a6
|
|
https://github.com/ruby/prism/commit/9a883a474a
|
|
https://github.com/ruby/prism/commit/336bd7249a
|
|
https://github.com/ruby/prism/commit/b6927ac714
|
|
https://github.com/ruby/prism/commit/88b8185075
|
|
https://github.com/ruby/prism/commit/b9d762c76a
|
|
https://github.com/ruby/prism/commit/4ba9abf664
|
|
https://github.com/ruby/prism/commit/7a277be5fb
|
|
Prism has been directly supported as a parser engine since RuboCop 1.62:
https://github.com/rubocop/rubocop/releases/tag/v1.62.0
This makes specifying `TargetRubyVersion` with special values like `80_82_73_83_77.33`
using the `prism/translation/parser/rubocop` file unnecessary.
As a result, it would be possible to deprecate this approach.
OTOH, early users might be surprised if `prism/translation/parser/rubocop` were to be suddenly removed.
Therefore, this PR deprecates the parameters related to `prism/translation/parser/rubocop`.
```console
$ bundle exec ruby -rrubocop -rprism/translation/parser/rubocop -e "RuboCop::AST::ProcessedSource.new('42', 80_82_73_83_77.33).ast"
WARN: Prism is directly supported since RuboCop 1.62. The `prism/translation/parser/rubocop` file is deprecated.
WARN: Setting `TargetRubyVersion: 80_82_73_83_77.33` is deprecated. Set to `ParserEngine: parser_prism` and `TargetRubyVersion: 3.3` instead.
$ bundle exec ruby -rrubocop -rprism/translation/parser/rubocop -e "RuboCop::AST::ProcessedSource.new('42', 80_82_73_83_77.34).ast"
WARN: Prism is directly supported since RuboCop 1.62. The `prism/translation/parser/rubocop` file is deprecated.
WARN: Setting `TargetRubyVersion: 80_82_73_83_77.34` is deprecated. Set to `ParserEngine: parser_prism` and `TargetRubyVersion: 3.4` instead.
```
Eventually, it will be possible to remove it at some point.
Regarding documentation, it has been updated to not show the old, discouraged usage but rather
the new way of specifying it in RuboCop.
https://github.com/ruby/prism/commit/0e4bc31463
|
|
https://github.com/ruby/time/commit/4abeaec776
|
|
(https://github.com/ruby/irb/pull/859)
This allows hierarchy when loading rc files for example both files below
are loaded;
project/.irbrc
~/.irbrc
https://github.com/ruby/irb/commit/b53ebc6655
Co-authored-by: Stan Lo <stan001212@gmail.com>
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
This reverts commit 0ae0a0c1c3bb01d118c5a924d731a2b3e9774105.
|
|
- Redirect stderr `git ls-files` to null without shelling out.
- When building by `gem`, `__FILE__` is the path name given in the
command line, or the gemspec file name in the current directory. In
that case, comparison it and expanded path never equal. Compare
listed file names with the base name of `__FILE__` instead.
https://github.com/rubygems/rubygems/commit/5583433dbb
|
|
This reverts commit 71d511615b8dac459d6f88f5896b9859f99c999e.
|
|
https://github.com/ruby/prism/commit/e1e613df16
|
|
https://github.com/ruby/prism/commit/dccfd83bc4
|
|
`Prism::Translation::Parser`
This PR fixes the following incompatibility AST for regexp match between Parser gem and Prism:
## Parser gem
Returns an `match_with_lvasgn` node:
```console
$ bundle exec ruby -rparser/ruby33 -ve 'p Parser::Ruby33.parse("/foo/ =~ bar")'
ruby 3.3.0 (2023-12-25 revision https://github.com/ruby/prism/commit/5124f9ac75) [x86_64-darwin22]
s(:match_with_lvasgn,
s(:regexp,
s(:str, "foo"),
s(:regopt)),
s(:send, nil, :bar))
```
## Prism (`Prism::Translation::Parser`)
### Before
Returns an `send` node:
```console
$ bundle exec ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("/foo/ =~ bar")'
ruby 3.3.0 (2023-12-25 revision https://github.com/ruby/prism/commit/5124f9ac75) [x86_64-darwin22]
s(:send,
s(:regexp,
s(:str, "foo"),
s(:regopt)), :=~,
s(:send, nil, :bar))
```
### After
Returns an `match_with_lvasgn` node:
```console
$ bundle exec ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("/foo/ =~ bar")'
ruby 3.3.0 (2023-12-25 revision https://github.com/ruby/prism/commit/5124f9ac75) [x86_64-darwin22]
s(:match_with_lvasgn,
s(:regexp,
s(:str, "foo"),
s(:regopt)),
s(:send, nil, :bar))
```
## Background
Found due to incompatibility with RuboCop's `Performance/EndWith`, `Performance/StringInclude,
and `Performance/StartWith` cops.
## Note
This is the incompatibility when the receiver is a regular expression literal and `=~` is used.
Based on the node name `:match_with_lvasgn`, it appears that Prism's AST becomes more accurate
in cases like `visit_match_write_node` only.
However, as shown in the background, the current behavior of Parser gem is not like this.
Considering compatibility with the published AST of Parser gem, the AST incompatibility will be addressed.
This lvar-injecting feature appears to have not been supported by Parser gem for a long time:
https://github.com/whitequark/parser/issues/69#issuecomment-19506391
There seems to be no indication that it will be supported.
This PR prioritizes AST compatibility between the Parser gem and Prism.
However, it is unclear whether this is the best approach.
https://github.com/ruby/prism/commit/dff4abb170
|
|
https://github.com/ruby/prism/commit/1fe507fe3d
|
|
https://github.com/ruby/prism/commit/c6c771d1fa
|
|
The `POSTLINK` variable had been used in the `LINK_SO` variable, which
is used to link shared extension libraries. However, the `POSTLINK`
variable had not been defined in the generated Makefile, so extension
libraries were not properly post-processed. It was not a critical issue
for the existing `POSTLINK` usage for darwin platforms, but it would be
a problem for Wasm/WASI platform, which requires *mandatory*
post-processing for shared extension libraries.
|
|
(https://github.com/ruby/irb/pull/888)
* Remove dead irb_level method
* Restructure workspace management
Currently, workspace is an attribute of IRB::Context in most use cases.
But when some workspace commands are used, like `pushws` or `popws`, a
workspace will be created and used along side with the original workspace
attribute.
This complexity is not necessary and will prevent us from expanding
multi-workspace support in the future.
So this commit introduces a @workspace_stack ivar to IRB::Context so IRB
can have a more natural way to manage workspaces.
* Fix pushws without args
* Always display workspace stack after related commands are used
https://github.com/ruby/irb/commit/61560b99b3
|
|
https://github.com/ruby/optparse/commit/77dccce37c
|
|
This patch implements handling of CAA resource records defined by [RFC8659].
- There are no known deployment of CAA records outside of IN (Internet),
but the RFC does not state that CAA records are class-specific.
Thus `CAA` class is defined as a class-independent RRType.
- `CAA` class stores `flags` field (a 1-octet bitset) as an Integer.
In this way it's easier to ensure the encoded RR is in the valid wire format.
[RFC8659]: https://datatracker.ietf.org/doc/html/rfc8659
https://github.com/ruby/resolv/commit/cfc4de75e3
Co-authored-by: aeris <aeris@imirhil.fr>
|
|
* TruffleRuby does support C extensions but FFI is faster there.
https://github.com/ruby/prism/commit/d211a87691
|
|
"AR" was well propagated to the enc.mk and mkmf, but "LD" was not. This
caused the dynamic libraries to be linked with a linker found in the PATH,
which could be different from the one used in the Ruby build process.
This is especially important for cross-compilation, where the host
linker may not be compatible with the target system. (e.g. WebAssembly)
|
|
https://github.com/ruby/prism/commit/369ffbd57e
|
|
https://github.com/ruby/prism/commit/4ef4032774
|
|
This PR fixes an incorrect parsing for `Prism::Translation::Parser`
when one-line pattern mathing with Ruby 2.7 runtime.
## Expected
Parsing should be done based on the specified Ruby parsing version,
independent of the Ruby runtime version. When parsing for Ruby 3.3,
it should return `:match_pattern_p` node:
```console
$ ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("foo in bar")'
ruby 3.0.6p216 (2023-03-30 revision https://github.com/ruby/prism/commit/23a532679b) [x86_64-darwin19]
s(:match_pattern_p,
s(:send, nil, :foo),
s(:match_var, :bar))
```
## Actual
When parsing with Ruby 2.7 runtime, `match_pattern` node is returned,
even though it is expected to parse for Ruby 3.3:
```console
$ ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("foo in bar")'
ruby 2.7.8p225 (2023-03-30 revision https://github.com/ruby/prism/commit/1f4d455848) [x86_64-darwin19]
s(:match_pattern,
s(:send, nil, :foo),
s(:match_var, :bar))
```
The cause was the use of `RUBY_VERSION` for condition logic,
which made it dependent on runtime Ruby version.
`Prism::Translation::Parser` supports parsing for Ruby 3.3+.
Therefore, the condition for parsing Ruby 2.7, which is not supported, is being removed.
## Background
Found due to incompatibility with RuboCop's `Layout/SpaceAroundKeyword` and `Style/TernaryParentheses` cops.
https://github.com/ruby/prism/commit/e752e251d2
|
|
With the introduction of `Prism::Translation::Parser` to RuboCop (RuboCop AST),
the number of arguments for `RuboCop::AST::ProcessedSource#parser_class` internal API will be changed:
https://github.com/rubocop/rubocop-ast/pull/277
## Before
As a result, the following error will occur starting from the next release of RuboCop AST (< 1.30.0) :
```console
$ bundle exec ruby -rrubocop/ast -rprism -rprism/translation/parser/rubocop -ve \
"p RuboCop::AST::ProcessedSource.new('42', 80_82_73_83_77.33).ast"
ruby 3.3.0 (2023-12-25 revision https://github.com/ruby/prism/commit/5124f9ac75) [x86_64-darwin22]
/Users/koic/src/github.com/ruby/prism/lib/prism/translation/parser/rubocop.rb:25:in `parser_class':
wrong number of arguments (given 2, expected 1) (ArgumentError)
from /Users/koic/src/github.com/rubocop/rubocop-ast/lib/rubocop/ast/processed_source.rb:309:in `create_parser'
from /Users/koic/src/github.com/rubocop/rubocop-ast/lib/rubocop/ast/processed_source.rb:219:in `parse'
from /Users/koic/src/github.com/rubocop/rubocop-ast/lib/rubocop/ast/processed_source.rb:47:in `initialize'
from -e:1:in `new'
from -e:1:in `<main>'
```
## After
This PR prevents the above error by updating the monkey patch to support the new argument:
```console
$ bundle exec ruby -rrubocop/ast -rprism -rprism/translation/parser/rubocop -ve \
"p RuboCop::AST::ProcessedSource.new('42', 80_82_73_83_77.33).ast"
ruby 3.3.0 (2023-12-25 revision https://github.com/ruby/prism/commit/5124f9ac75) [x86_64-darwin22]
s(:int, 42)
```
Moreover, to ensure compatibility with the existing RuboCop AST, conditional logic
has been implemented to maintain backward compatibility.
https://github.com/ruby/prism/commit/8a6909f4d5
|
|
https://github.com/ruby/prism/commit/959eb506ca
|
|
specification attribute.
https://github.com/rubygems/rubygems/commit/e4bb33747a
|
|
https://github.com/ruby/tmpdir/commit/3f1f2260eb
|
|
https://github.com/ruby/tempfile/commit/f224164979
|
|
https://github.com/rubygems/rubygems/commit/3f5093fac9
|
|
https://github.com/rubygems/rubygems/commit/d004e36c44
|
|
https://github.com/rubygems/rubygems/commit/93514afa28
|
|
https://github.com/rubygems/rubygems/commit/d198ec36f2
|
|
'vendored_' prefix
https://github.com/rubygems/rubygems/commit/cfc908c8c1
|
|
https://github.com/ruby/prism/commit/4e0f703975
|
|
https://github.com/ruby/prism/commit/eeae07193b
|
|
https://github.com/ruby/prism/commit/5877a95be4
|
|
- Redirect `git ls-files` without shelling out.
- When building by `gem`, `__FILE__` is the path name given in the
command line, or the gemspec file name in the current directory. In
that case, comparison it and expanded path never equal. Compare
listed file names with the base name of `__FILE__` instead.
https://github.com/ruby/tempfile/commit/ac5bab8c7a
|
|
|