-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Make concatenation of SubString{AnnotatedString} preserve annotations #51806
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
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. |
LilithHafner
left a comment
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
enddoesn'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 |
SubStringshave 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.