Explicitly freeze concatenated-String
constants to unbreak on non-main Ractor
s.
#449
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When building
String
s with theString#concat
/String#+
methods, the receiver and argumentString
s are literals, but the resulting value is not, so they are left unfrozen when we rely only on thefrozen_string_literal
directive.Switch to the
%q
non-interpolableString
literal syntax for these because it feels less gross to me than e.g.HOST = (UNRESERVED + SUB_DELIMS + "\\[\\:\\]").freeze
. This syntax was present in Ruby 2.0, which is Addressable's minimum requirement :)Before
Concatenated
String
s are not frozen when thefrozen_string_literal: true
directive is used.…and we encounter a
Ractor::IsolationError
when trying to useAddressable::URI::parse
in a non-mainRactor
:After
String
s are frozen, and Addressable can be used in a non-mainRactor
:Even though
Ractor::shareable?
still returnsfalse
here, the Ractor "shareable objects" docs say frozenString
objects are shareable. We could additionally callRactor::make_shareable
, but there seems to be no reason to since it does work: