-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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.
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
Make concatenation of SubString{AnnotatedString} preserve annotations #51806
Make concatenation of SubString{AnnotatedString} preserve annotations #51806
Conversation
a1ed366
to
8e2dd0d
Compare
I must admit, I can't see what's going on with CI here. |
8e2dd0d
to
dc71228
Compare
Just pushed the use of |
dc71228
to
f13ee94
Compare
The CI failure seems unrelated:
|
f13ee94
to
91c4266
Compare
SubStrings have been overlooked, and thanks to a few compiler quirks (relating to inlining and effect analysis), adding support for them is unfortunately a little more complicated than adding a "|| s isa SubString{<:AnnotatedString}" clause thanks to the new generated runtime-checks. To maintain the zero-overhead non-annotated code path, we need to implement a separate function _isannotated, which we also make use of to simplify the current join method. A SubString{AnnotatedString} value is added to the Annotated{String,Char} concatenation test block.
91c4266
to
afeaee3
Compare
Now with tests :) |
Ok, what's going on with CI? It seems consistently on the fritz again. |
I'd think this to be a pretty straightforward small improvement that could be quickly merged, is there anything holding this back? |
It would be great if somebody with merge rights could spare the time to have a look at this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This construction
if annotated
annotatedstring
else
string
end
doesn't feel natural in the generic-function/multiple-dispatch paradigm, which makes me averse to touching this. However, that aversion does not block this PR as this PR simply improves the situation by shifting some existing hardcoded || statements into generic functions (in order fix some substring functionality)
I get that aversion. However, the reason why "if annotated" now pops up in a few places is because it's extended a status quo of "hardcoded I do recall Valentin (Churavy) suggesting that |
SubStrings
have been overlooked, and thanks to a few compiler quirks (relating to inlining and effect analysis), adding support for them is unfortunately a little more complicated than adding a|| s isa SubString{<:AnnotatedString}
clause thanks to the new generated runtime-checks.To maintain the zero-overhead non-annotated code path, we need to implement a separate function
_isannotated
, which we also make use of to simplify the current join method.