| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
Push the newly refactored lldb files into a sub-directory so that we're
not cluttering up the misc directory
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If we are expanding the string or only stripping extra capacity
then coderange won't change, so clearing it is wasteful.
|
|
|
|
|
|
|
| |
[Feature #18944]
If both `non_block=true` and `timeout:` are supplied, ArgumentError
is raised.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Check out the revisions for testing as "detached" from the beginning.
|
| |
|
| |
|
|
|
|
|
| |
GC could be in an intermediate state after creating the objects, so we
should finish GC by running a minor GC.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/488f89aee4
|
| |
|
|
|
|
|
|
|
|
| |
* Simplify around `USE_YJIT` macro
- Use `USE_YJIT` macro only instead of `YJIT_BUILD`.
- An intermediate macro `YJIT_SUPPORTED_P` is no longer used.
* Bail out if YJIT is enabled on unsupported platforms
|
|
|
|
| |
This test will prevent performance regressions like [Bug #18929].
|
|
|
|
| |
https://github.com/ruby/date/commit/59a6673221
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/0d321c9e3a
|
| |
|
|
|
|
|
|
| |
Fixes [Bug #13864]
https://github.com/ruby/rinda/commit/3cd620f38c
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
(https://github.com/ruby/rdoc/pull/917)
https://github.com/ruby/rdoc/commit/c40bac829c
|
| |
|
| |
|
| |
|
| |
|
| |
|