Skip to content

Update bootsnap: 1.9.1 → 1.10.3 (minor) #199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
depfu wants to merge 1 commit into from
Closed

Update bootsnap: 1.9.1 → 1.10.3 (minor) #199

depfu wants to merge 1 commit into from

Conversation

@depfu
Copy link
Contributor

@depfu depfu bot commented Feb 3, 2022

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ bootsnap (1.9.1 → 1.10.3) · Repo · Changelog

Release Notes

1.10.3 (from changelog)

  • Fix Regexp and Date type support in YAML compile cache. (#400)

  • Improve the YAML compile cache to support UTF-8 symbols. (#398, #399) The default MessagePack symbol serializer assumes all symbols are ASCII, because of this, non-ASCII compatible symbol would be restored with ASCII_8BIT encoding (AKA BINARY). Bootsnap now properly cache them in UTF-8.

    Note that the above only apply for actual YAML symbols (e..g --- :foo). The issue is still present for string keys parsed with YAML.load_file(..., symbolize_names: true), that is a bug in msgpack that will hopefully be solved soon, see: msgpack/msgpack-ruby#246

  • Entirely disable the YAML compile cache if Encoding.default_internal is set to an encoding not supported by msgpack. (#398) Psych coerce strings to Encoding.default_internal, but MessagePack doesn't. So in this scenario we can't provide YAML caching at all without returning the strings in the wrong encoding. This never came up in practice but might as well be safe.

1.10.2 (from changelog)

  • Reduce the Kernel.require extra stack frames some more. Now bootsnap should only add one extra frame per require call.

  • Better check freeze option support in JSON compile cache. Previously JSON.load_file(..., freeze: true) would be cached even when the msgpack version is missing support for it.

1.10.1 (from changelog)

  • Fix Kernel#autoload's fallback path always being executed.

  • Consider unlink failing with ENOENT as a success.

1.10.0 (from changelog)

  • Delay requiring FileUtils. (#285) FileUtils can be installed as a gem, so it's best to wait for bundler to have setup the load path before requiring it.

  • Improve support of Psych 4. (#392) Since 1.8.0, YAML.load_file was no longer cached when Psych 4 was used. This is because load_file loads in safe mode by default, so the Bootsnap cache could defeat that safety. Now when precompiling YAML files, Bootsnap first try to parse them in safe mode, and if it can't fallback to unsafe mode, and the cache contains a flag that records wether it was generated in safe mode or not. YAML.unsafe_load_file will use safe caches just fine, but YAML.load_file will fallback to uncached YAML parsing if the cache was generated using unsafe parsing.

  • Minimize the Kernel.require extra stack frames. (#393) This should reduce the noise generated by bootsnap on LoadError.

1.9.4 (from changelog)

  • Ignore absolute paths in the loaded feature index. (#385) This fixes a compatibility issue with Zeitwerk when Zeitwerk is loaded before bootsnap. It also should reduce the memory usage and improve load performance of Zeitwerk managed files.

  • Automatically invalidate the load path cache whenever the Ruby version change. (#387) This is to avoid issues in case the same installation path is re-used for subsequent ruby patch releases.

1.9.3 (from changelog)

  • Only disable the compile cache for source files impacted by Ruby 3.0.3 [Bug 18250]. This should keep the performance loss to a minimum.

1.9.2 (from changelog)

  • Disable compile cache if Ruby 3.0.3's ISeq cache bug is detected. AKA iseq.rb:13 to_binary: wrong argument type false (expected Symbol)
  • Fix Kernel.load behavior: before load 'a' would load a.rb (and other tried extensions) and wouldn't load a unless development_mode: true, now only a would be loaded and files with extensions wouldn't be.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 59 commits:

↗️ msgpack (indirect, 1.4.2 → 1.4.4) · Repo · Changelog

Release Notes

1.4.4 (from changelog)

* Specify the build option --platform=8 for older Java platforms

1.4.3 (from changelog)

* Optimize serialization/deserialization of Symbols
* Support registering ext types for objects of subclasses of primitive types (like Hash)
* Add optimized_symbols_parsing option to Factory#register_type on MRI implementation
* Optimize to deduplicate Hash keys on JRuby
* Support JRuby 9.3 (and drop 9.1)

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 53 commits:

Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)
Go to the Depfu Dashboard to see the state of your dependencies and to customize how Depfu works.

@depfu depfu bot added depfu valet:merge Automerge labels Feb 3, 2022
@depfu depfu bot mentioned this pull request Feb 3, 2022
Closed
@depfu
Copy link
Contributor Author

depfu bot commented Mar 9, 2022

Closed in favor of #206.

@depfu depfu bot closed this Mar 9, 2022
@depfu depfu bot deleted the depfu/update/bootsnap-1.10.3 branch March 9, 2022 11:19
@depfu
Copy link
Contributor Author

depfu bot commented Mar 9, 2022

Closed in favor of #206.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

bootsnap depfu valet:merge Automerge

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants