| Age | Commit message (Collapse) | Author |
|
Related to https://github.com/Shopify/yjit-bench/pull/109
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6258
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6258
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6254
|
|
ArgumentError
https://github.com/ruby/error_highlight/commit/defcaf1beb
|
|
|
|
Not only `J` is called military timezone.
|
|
|
|
```
$ tool/sync_default_gems.rb syntax_suggest
```
Notes:
Merged: https://github.com/ruby/ruby/pull/5859
|
|
Adds the `syntax_suggest` syntax error display tool to Ruby through the same mechanism as `error_highlight` and `did_you_mean`. Reference ticket: https://bugs.ruby-lang.org/issues/18159
close #4845
## What is syntax_suggest?
When a syntax error is raised by requiring a file, dead_end will use a combination of indentation and lexing to identify the problem.
> Note: Previously this tool was named `dead_end`.
## Known issues
- SyntaxSearch's approach of showing syntax errors only works through integration with `require`, `load`, `autoload`, and `require_relative` (since it monkeypatches them to detect syntax errors). It does not work with direct Ruby file invocations https://github.com/zombocom/dead_end/issues/31.
- This causes failure in the test suite (test_expected_backtrace_location_when_inheriting_from_basic_object_and_including_kernel) and confusion when inspecting backtraces if there's a different error when trying to require a file such as measuring memory (https://github.com/zombocom/syntax_suggest/issues/124#issuecomment-1006705016).
- Discussed fix. We previously talked about opening up `SyntaxError` to be monkeypatched in the same way that other gems hook into `NoMethodError`. This is currently not possible and requires development work. When we last talked about it at RubyKaigi Nobu expressed an ability to make such a change.
Notes:
Merged: https://github.com/ruby/ruby/pull/5859
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5977
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6073
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6253
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6253
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6253
|
|
|
|
by moving it fully into RbBaseCommand
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Push the newly refactored lldb files into a sub-directory so that we're
not cluttering up the misc directory
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
`lldb_cruby.py` manages lldb custom commands using functions. The file
is a large list of Python functions, and an init handler to map some of
the Python functions into the debugger, to enable execution of custom
logic during a debugging session.
Since LLDB 3.7 (September 2015) there has also been support for using
python classes rather than bare functions, as long as those classes
implement a specific interface.
This PR Introduces some more defined structure to the LLDB helper
functions by switching from the function based implementation to the
class based one, and providing an auto-loading mechanism by which new
functions can be loaded.
The intention behind this change is to make working with the LLDB
helpers easier, by reducing code duplication, providing a consistent
structure and a clearer API for developers.
The current function based approach has some advantages and
disadvantages
Advantages:
- Adding new code is easy.
- All the code is self contained and searchable.
Disadvantages:
- No visible organisation of the file contents. This means
- Hard to tell which functions are utility functions and which are
available to you in a debugging session
- Lots of code duplication within lldb functions
- Large files quickly become intimidating to work with - for example,
`lldb_disasm.py` was implemented as a seperate Python module because
it was easier to start with a clean slate than add significant amounts
of code to `lldb_cruby.py`
This PR attempts, to fix the disadvantages of the current approach and
maintain, or enhance, the benefits. The new structure of a command looks
like this;
```
class TestCommand(RbBaseCommand):
# program is the keyword the user will type in lldb to execute this command
program = "test"
# help_string will be displayed in lldb when the user uses the help functions
help_string = "This is a test command to show how to implement lldb commands"
# call is where our command logic will be implemented
def call(self, debugger, command, exe_ctx, result):
pass
```
If the command fulfils the following criteria it will then be
auto-loaded when an lldb session is started:
- The package file must exist inside the `commands` directory and the
filename must end in `_command.py`
- The package must implement a class whose name ends in `Command`
- The class inherits from `RbBaseCommand` or at minimum a class that
shares the same interface as `RbBaseCommand` (at minimum this means
defining `__init__` and `__call__`, and using `__call__` to call
`call` which is defined in the subclasses).
- The class must have a class variable `package` that is a String. This
is the name of the command you'll call in the `lldb` debugger.
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6252
|
|
|
|
|
|
|
|
|
|
If we are expanding the string or only stripping extra capacity
then coderange won't change, so clearing it is wasteful.
Notes:
Merged: https://github.com/ruby/ruby/pull/6178
|
|
[Feature #18944]
If both `non_block=true` and `timeout:` are supplied, ArgumentError
is raised.
Notes:
Merged: https://github.com/ruby/ruby/pull/6207
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6250
|
|
icc now seems to provide libutil.so that is not related to pty.
This extconf.rb wrongly finds it and adds `-lutil`, but `ruby -rpty`
fails because it cannot find libutil.so on the runtime.
http://rubyci.s3.amazonaws.com/icc-x64/ruby-master/log/20220815T210005Z.fail.html.gz
```
Exception raised:
<#<LoadError: libutil.so: cannot open shared object file: No such file or directory - /home/chkbuild/chkbuild/tmp/build/20220815T210005Z/ruby/.ext/x86_64-linux/pty.so>>
```
This change makes extconf.rb check libutil only on OpenBSD.
Notes:
Merged: https://github.com/ruby/ruby/pull/6249
|
|
Check out the revisions for testing as "detached" from the beginning.
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6247
|
|
GC could be in an intermediate state after creating the objects, so we
should finish GC by running a minor GC.
Notes:
Merged: https://github.com/ruby/ruby/pull/6245
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6239
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6239
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6239
|
|
Set `date` member to `RUBY_RELEASE_DATE` instead of the date at the
build time, to make installed files reproducible.
|
|
- Split into `Ext` and `Lib` classes.
- `Ext#files` should not include built extension libraries.
- `Ext#files` should include scripts under its own `lib`.
- `Lib#files` should be prefixed with `lib/`.
|
|
|
|
|
|
[Feature #18822]
Ruby is somewhat missing an RFC 3986 compliant escape method.
https://github.com/ruby/cgi/commit/c2729c7f33
|
|
|
|
* Optimize Marshal dump of large fixnum
Marshal's FIXNUM type only supports 31-bit fixnums, so on 64-bit
platforms the 63-bit fixnums need to be represented in Marshal's
BIGNUM.
Previously this was done by converting to a bugnum and serializing the
bignum object.
This commit avoids allocating the intermediate bignum object, instead
outputting the T_FIXNUM directly to a Marshal bignum. This maintains the
same representation as the previous implementation, including not using
LINKs for these large fixnums (an artifact of the previous
implementation always allocating a new BIGNUM).
This commit also avoids unnecessary st_lookups on immediate values,
which we know will not be in that table.
* Fastpath for loading FIXNUM from Marshal bignum
* Run update-deps
Notes:
Merged-By: jhawthorn <john@hawthorn.email>
|
|
I noticed that this site unconditionally clones the method entry, which
means that `bind_call` always allocates a `T_IMEMO`. While this clone
is necessary for `bind`, it is not necessary for `bind_call`.
I work at Stripe, and the sorbet_runtime gem uses bind call as part
of it's [call validation](https://github.com/sorbet/sorbet/blob/master/gems/sorbet-runtime/lib/types/private/methods/call_validation.rb#L157)
so this can save us a lot of allocations.
This patch adds a `clone` parameter to `convert_umethod_to_method_components`,
which then controls whether or not we do this cloning. This patch passed
Stripe CI and works in our QA environment. I reviewed it with @tenderlove
to talk about correctness also.
Notes:
Merged: https://github.com/ruby/ruby/pull/6244
|
|
https://github.com/ruby/rdoc/commit/488f89aee4
|
|
|