Deprecate Kernel#open and IO support for subprocess creation and
forking. This deprecates subprocess creation and forking in
- Kernel#open
- URI.open
- IO.binread
- IO.foreach
- IO.readlines
- IO.read
- IO.write
This behavior is slated to be removed in Ruby 4.0
[Feature #19630]
{Nil,True,False}Class#singleton_methods always returns [] indicating
that there are no singleton methods defined, so #singleton_method
should be consistent with that.
Fixes [Bug #11064]
[Feature #19755]
Before (in /tmp/test.rb):
```ruby
Object.class_eval("p __FILE__") # => "(eval)"
```
After:
```ruby
Object.class_eval("p __FILE__") # => "(eval at /tmp/test.rb:1)"
```
This makes it much easier to track down generated code in case
the author forgot to provide a filename argument.
[Feature #18885]
For now, the optimizations performed are:
- Run a major GC
- Compact the heap
- Promote all surviving objects to oldgen
Other optimizations may follow.
Previously, when sorting and comparing git Gemfile vs lockfile sources during
`bundler/setup` to figure out whether we need to re-resolve or not, we
would try to find the default branch if nothing more specific was
specified in the Gemfile.
If the git cache has been deleted thought, that would fail.
The error would still be swallowed (and the branch would simply not be
displayed), but trying to clone would still generate the side effect of
creating the parent folder for the clone.
That could affect non-writable systems that don't expect `bundler/setup`
to write to the filesystem at all.
To fix this, override `Bundler::Source::Git#identifier` to use
exclusively static information, so it does not even try to clone the
repo nor generate any side effects.
https://github.com/rubygems/rubygems/commit/582eb2ef39
We have some flags that limit running git commit commands under certain
situations, for example, when running under `--local`. However, those
should only affect remote git operations, not local read-only operations
like `git --version`, or `git rev-parse --abbrev-ref HEAD`.
This commit refactors things to achieve that.
By doing this, the `#to_s` representation of a source is more
consistent, since we don't get any errors when reading the checked out
branch, and we avoid some flip-flop lockfile issues.
https://github.com/rubygems/rubygems/commit/4a529fce81
When dependencies in path sources have changed, we'll be re-resolving,
and we can't really know whether the resolution will be valid or invalid
for the Ruby platform, so skip the removal in that case.
https://github.com/rubygems/rubygems/commit/afc3b0956f
This error message is also printed when using `bundler/setup` in frozen
model, so we're not necessarily installing any gems when it happens.
This new message play nicer with all situations.
https://github.com/rubygems/rubygems/commit/6874bbacce
Similarly to how the other ignored files are intended for local
development and not for production, the Gemfile and Gemfile.lock files
for a gem only relate to local development and aren't useful to people
installing the gem.
https://github.com/rubygems/rubygems/commit/59049c04be
If we're in inline mode, Bundler first resolves using only local gems,
and if some gems are missing, then it re-resolves using remote gems.
However, "source resolution" from the initial "local" try was being
memoized, resulting in Bundler not looking for some gems remotely in the
second resolution.
This commit forces a proper re-resolve in this case.
https://github.com/rubygems/rubygems/commit/fdc631075e
* Add rb_io_path and rb_io_open_descriptor.
* Use rb_io_open_descriptor to create PTY objects
* Rename FMODE_PREP -> FMODE_EXTERNAL and expose it
FMODE_PREP I believe refers to the concept of a "pre-prepared" file, but
FMODE_EXTERNAL is clearer about what the file descriptor represents and
aligns with language in the IO::Buffer module.
* Ensure that rb_io_open_descriptor closes the FD if it fails
If FMODE_EXTERNAL is not set, then it's guaranteed that Ruby will be
responsible for closing your file, eventually, if you pass it to
rb_io_open_descriptor, even if it raises an exception.
* Rename IS_EXTERNAL_FD -> RUBY_IO_EXTERNAL_P
* Expose `rb_io_closed_p`.
* Add `rb_io_mode` to get IO mode.
---------
Co-authored-by: KJ Tsanaktsidis <ktsanaktsidis@zendesk.com>
[Feature #19236]
In Ruby 3.3, `Hash.new` shall print a deprecation warning if keyword arguments
are passed instead of treating them as an implicit positional Hash.
This will allow to safely introduce a `capacity` keyword argument in 3.4
Co-authored-by: Jean Boussier <byroot@ruby-lang.org>
https://github.com/ruby/syntax_suggest/pull/187 Handle if/else with
empty/comment
line
Reported in #187 this code:
```
class Foo
def foo
if cond?
foo
else
# comment
end
end
# ...
def bar
if @recv
end_is_missing_here
end
end
```
Triggers an incorrect suggestion:
```
Unmatched keyword, missing `end' ?
1 class Foo
2 def foo
> 3 if cond?
> 5 else
8 end
16 end
```
Part of the issue is that while scanning we're using newlines to determine when to stop and pause. This is useful for determining logically smaller chunks to evaluate but in this case it causes us to pause before grabbing the "end" that is right below the newline. This problem is similar to https://github.com/ruby/syntax_suggest/pull/179.
However in the case of expanding same indentation "neighbors" I want to always grab all empty values at the end of the scan. I don't want to do that when changing indentation levels as it affects scan results.
There may be some way to normalize this behavior between the two, but the tests really don't like that change.
To fix this issue for expanding against different indentation I needed a way to first try and grab any additional newlines with the ability to rollback that guess. In #192 I experimented with decoupling scanning from the AroundBlockScan logic. It also added the ability to take a snapshot of the current scanner and rollback to prior changes.
With this ability in place now we:
- Grab extra empties before looking at the above/below line for the matching keyword/end statement
- If there's a match, grab it
- If there's no match, discard the newlines we picked up in the evaluation
That solves the issue.
https://github.com/ruby/syntax_suggest/commit/513646b912
AroundBlockScan started as a utility class that was meant to be used as a DSL for scanning and making new blocks. As logic got added to this class it became hard to reason about what exactly is being mutated when. I pulled the scanning logic out into it's own class which gives us a clean separation of concerns. This allowed me to remove a lot of accessors that aren't core to the logic provided by AroundBlockScan.
In addition to this refactor the ScanHistory class can snapshot a scan. This allows us to be more aggressive with scans in the future as we can now snapshot and rollback if it didn't turn out the way we wanted.
The change comes with a minor perf impact:
before: 5.092678 0.104299 5.196977 ( 5.226494)
after: 5.128536 0.099871 5.228407 ( 5.249542)
This represents a 0.996x change in speed (where 1x would be no change and 2x would be twice as fast). This is a 0.38% decrease in performance which is negligible. It's likely coming from the extra blocks being created while scanning. This is negligible and if the history feature works well we might be able to make better block decisions which is means fewer calls to ripper which is the biggest bottleneck.
While this doesn't fix https://github.com/ruby/syntax_suggest/issues/187 it's a good intermediate step that will hopefully make working on that issue easier.
https://github.com/ruby/syntax_suggest/commit/ad8487d8aa
I previously left a comment stating I didn't know why a certain method existed. In investigating the code in `CaptureCodeContext#capture_before_after_kws` I found that it was added as to give a slightly less noisy output.
The docs for AroundBlockScan#capture_neighbor_context only describe keywords as being a primary concern. I modified that code to only include lines that are keywords or ends. This reduces the output noise even more.
This allows me to remove that `start_at_next_line` method.
One weird side effect of the prior logic is it would cause this code to produce this output:
```
class OH
def hello
def hai
end
end
```
```
1 class OH
> 2 def hello
4 def hai
5 end
6 end
```
But this code to produce this output:
```
class OH
def hello
def hai
end
end
```
```
1 class OH
> 2 def hello
4 end
5 end
```
Note the missing `def hai`. The only difference between them is that space.
With this change, they're now both consistent.
https://github.com/ruby/syntax_suggest/commit/4a54767a3e
`GETRUSAGE_BASED_CLOCK_PROCESS_CPUTIME_ID` clock uses `getrusage`
always if available as the name states. That is if it is implemented
`getrusage` is available, regardless microseconds in its results.
Prior to commit 5806c54447, it was "at
least one result with precision beyond milliseconds (with none-zero
microseconds) should exist"; after this commit, "at least one result
should have zero microseconds". This chance is lower than the
previous condition.
Since these files are written in a wide character encoding, stop at
first NUL byte and are actually empty. ASCII-incompatible encodings
have never been supported as source encoding.
Nobuyoshi Nakada
Mike Dalessio
Benoit Daloze
Hiroshi SHIBATA
Jeremy Evans
Jean Boussier
David Rodríguez
Jean Boussier
alexandre184
Takashi Kokubun
Ellen Marie Dash
Samuel Williams
Gareth Adams
NARUSE, Yui
Peter Zhu
Jean byroot Boussier
schneems
Ivanov-Anton
Martin Dürst
Vladimir Dementyev
git