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
61560b99b3
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/rfc8659cfc4de75e3
Co-authored-by: aeris <aeris@imirhil.fr>
"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)
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 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 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.
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 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 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.
8a6909f4d5
- 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.
ac5bab8c7a
- 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.
f505e3f7cb
(https://github.com/ruby/reline/pull/637)
I think this has a few benefits:
1. Most terminal themes generally don't change or pick similar colors
for their black and white colors, so it's more likely to be consistent
across terminals/themes.
2. They don't have the potential color-blind issues that other color options
may have.
3. We won't need additional changes for no color mode.
6579a0a737
