Skip to content
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

Add annotate! method for AnnotatedIOBuffer #53284

Merged
merged 1 commit into from
Feb 23, 2024

Conversation

tecosaur
Copy link
Contributor

The annotate! function provides a convenient way of adding annotations to an AnnotatedString/AnnotatedChar without accessing any of the implementation details of the Annotated* types.

When AnnotatedIOBuffer was introduced, an appropriate annotations method was added, but annotate! was missed. To correct that, we refactor the current annotate! method for AnnotatedString to a more general helper function _annotate! that operates on the annotation vector itself, and use this new helper method to easily provide an annotate! method for AnnotatedIOBuffer.

@tecosaur tecosaur added domain:io Involving the I/O subsystem: libuv, read, write, etc. domain:strings "Strings!" labels Feb 11, 2024
Copy link
Sponsor Member

@vtjnash vtjnash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests are broken, but the overall PR direction LGTM. Merge when passing

I do still find it strange that there is a mutation API for one particular AbstractString type, though not new here

The annotate! function provides a convenient way of adding annotations
to an AnnotatedString/AnnotatedChar without accessing any of the
implementation details of the Annotated* types.

When AnnotatedIOBuffer was introduced, an appropriate annotations method
was added, but annotate! was missed. To correct that, we refactor the
current annotate! method for AnnotatedString to a more general helper
function _annotate! that operates on the annotation vector itself, and
use this new helper method to easily provide an annotate! method for
AnnotatedIOBuffer.
@tecosaur tecosaur force-pushed the add-annotate-method-for-annio branch from 2a0c9e2 to 8c9d008 Compare February 12, 2024 16:44
@tecosaur
Copy link
Contributor Author

Ah ooops, somehow I had the tests fixed locally but the fix managed to escape the commit I pushed. Resolved now.

@tecosaur
Copy link
Contributor Author

I do still find it strange that there is a mutation API for one particular AbstractString type, though not new here.

The way I'd look at/frame that is that the string of an AnnotatedString is still immutable, but the annotations layer sits on top of that, and while mutable has no bearing on the actual content of the string.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Feb 12, 2024

Does it have relevance for the hash or equality of the string though?

@vtjnash vtjnash added the status:merge me PR is reviewed. Merge when all tests are passing label Feb 12, 2024
@tecosaur
Copy link
Contributor Author

Annotations are ignored when compared to other AbstractStrings, but == on two AnnotatedStrings does also compare the annotations. IIRC there was some discussion on how equality should work in the original PR, though I forget the details at this point.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Feb 12, 2024

That violates transitivity of == though, which is not mandatory, but is usually expected

@tecosaur
Copy link
Contributor Author

The behaviour of == with AnnotatedStrings is something I found difficult to work out, I'm personally still open to being convinced it should be done differently, it doesn't seem clear-cut to me.

@oscardssmith
Copy link
Member

IMO it probably should be that an unannotated string is equal to an annotated string iff there aren't any annotations.

@adienes
Copy link
Contributor

adienes commented Feb 15, 2024

agree preferable IMO to retain transitivity

one can always strip/empty the annotations before comparing

@tecosaur tecosaur added the backport 1.11 Change should be backported to release-1.11 label Feb 16, 2024
@fingolfin
Copy link
Contributor

I also agree with @oscardssmith's proposal. Transitivity is not just nice, but in my experience failure to adhere to it can lead to really weird and difficult to debug situations, e.g. when using strings as key in dictionaries.

But that's not a blocker for this PR which does not modify hashing / equality code, does it?

@fingolfin fingolfin merged commit 6e1d062 into JuliaLang:master Feb 23, 2024
7 of 9 checks passed
@inkydragon inkydragon removed the status:merge me PR is reviewed. Merge when all tests are passing label Feb 24, 2024
KristofferC pushed a commit that referenced this pull request Feb 26, 2024
The annotate! function provides a convenient way of adding annotations
to an AnnotatedString/AnnotatedChar without accessing any of the
implementation details of the Annotated* types.

When AnnotatedIOBuffer was introduced, an appropriate annotations method
was added, but annotate! was missed. To correct that, we refactor the
current annotate! method for AnnotatedString to a more general helper
function _annotate! that operates on the annotation vector itself, and
use this new helper method to easily provide an annotate! method for
AnnotatedIOBuffer.

(cherry picked from commit 6e1d062)
@KristofferC KristofferC mentioned this pull request Feb 26, 2024
28 tasks
KristofferC added a commit that referenced this pull request Mar 1, 2024
Backported PRs:
- [x] #53361 <!-- 🤖 [master] Bump the SparseArrays stdlib from c9f7293
to cb602d7 -->
- [x] #53300 <!-- allow external absint to hold custom data in
`codeinst.inferred` -->
- [x] #53342 <!-- Add `Base.wrap` to docs -->
- [x] #53372 <!-- Silence warnings in `test/file.jl` -->
- [x] #53357 <!-- 🤖 [master] Bump the Pkg stdlib from 6dd0e7c9e to
76070d295 -->
- [x] #53373 <!-- fix sysimage-native-code=no option with pkgimages -->
- [x] #53333 <!-- More consistent return value for annotations, take 2
-->
- [x] #53354 <!-- fix code coverage bug in tail position and `else` -->
- [x] #53407 <!-- fix sysimage-native-code=yes option -->
- [x] #53388 <!-- Fix documentation: thread pool of main thread -->
- [x] #53355 <!-- Fix synchronization issues on the GC scheduler. -->
- [x] #53429 <!-- Subtype: skip slow-path in `local_∀_∃_subtype` if
inputs contain no ∃ typevar. -->
- [x] #53437 <!-- Add debug variant of loader_trampolines.o -->
- [x] #53284 <!-- Add annotate! method for AnnotatedIOBuffer -->
- [x] #53466 <!-- [MozillaCACerts_jll] Update to v2023-12-12 -->
- [x] #53467 <!-- [LibGit2_jll] Update to v1.7.2 -->
- [x] #53326 <!-- RFC: when loading code for internal purposes, load
stdlib files directly, bypassing DEPOT_PATH, LOAD_PATH, and stale checks
-->
- [x] #53332
- [x] #53320 <!-- Add `Sys.isreadable, Sys.iswriteable`, update `ispath`
-->
- [x] #53476

Contains multiple commits, manual intervention needed:
- [ ] #53285 <!-- Add update mechanism for Terminfo, and common
user-alias data -->

Non-merged PRs with backport label:
- [ ] #53424 <!-- yet more atomics & cache-line fixes on work-stealing
queue -->
- [ ] #53408 <!-- task splitting: change additive accumulation to
multiplicative -->
- [ ] #53403 <!-- Move parallel precompilation to Base -->
- [ ] #53402 <!-- Add `jl_getaffinity` and `jl_setaffinity` -->
- [ ] #53391 <!-- Default to the medium code model in x86 linux -->
- [ ] #53125 <!-- coverage: count coverage where explicitly requested by
inference only -->
- [ ] #52694 <!-- Reinstate similar for AbstractQ for backward
compatibility -->
@KristofferC KristofferC removed the backport 1.11 Change should be backported to release-1.11 label Mar 1, 2024
@tecosaur
Copy link
Contributor Author

tecosaur commented Mar 2, 2024

IMO it probably should be that an unannotated string is equal to an annotated string iff there aren't any annotations.

Just checked (was about to make a "transitive equality for AnnotatedStrings") PR, but it looks like this is how it works already. The cmp implementation may need tweaking though.

# Avoid the iteration fallback with comparison
cmp(a::AnnotatedString, b::AbstractString) = cmp(a.string, b)
cmp(a::AbstractString, b::AnnotatedString) = cmp(a, b.string)
# To avoid method ambiguity
cmp(a::AnnotatedString, b::AnnotatedString) = cmp(a.string, b.string)

==(a::AnnotatedString, b::AnnotatedString) =
    a.string == b.string && a.annotations == b.annotations

==(a::AnnotatedString, b::AbstractString) = isempty(a.annotations) && a.string == b
==(a::AbstractString, b::AnnotatedString) = isempty(b.annotations) && a == b.string

tecosaur added a commit to tecosaur/julia that referenced this pull request Mar 4, 2024
The annotate! function provides a convenient way of adding annotations
to an AnnotatedString/AnnotatedChar without accessing any of the
implementation details of the Annotated* types.

When AnnotatedIOBuffer was introduced, an appropriate annotations method
was added, but annotate! was missed. To correct that, we refactor the
current annotate! method for AnnotatedString to a more general helper
function _annotate! that operates on the annotation vector itself, and
use this new helper method to easily provide an annotate! method for
AnnotatedIOBuffer.
mkitti pushed a commit to mkitti/julia that referenced this pull request Mar 7, 2024
The annotate! function provides a convenient way of adding annotations
to an AnnotatedString/AnnotatedChar without accessing any of the
implementation details of the Annotated* types.

When AnnotatedIOBuffer was introduced, an appropriate annotations method
was added, but annotate! was missed. To correct that, we refactor the
current annotate! method for AnnotatedString to a more general helper
function _annotate! that operates on the annotation vector itself, and
use this new helper method to easily provide an annotate! method for
AnnotatedIOBuffer.
@tecosaur tecosaur deleted the add-annotate-method-for-annio branch May 2, 2024 09:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:io Involving the I/O subsystem: libuv, read, write, etc. domain:strings "Strings!"
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants