Closed asmello closed 2 weeks ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 99.0%. Comparing base (
c96007e
) to head (aeb33b1
).
I think the sanitizer test is failing due to a bug in the sanitizer itself (given the obscure error referencing its source code).
My guess is https://github.com/rust-lang/rust/issues/111073
I'm at the fair with my family but noticed this come through and just wanted to say that I'm stoked about this one. I considered suggesting exposing Pointer::new but was hesitant.
I'll review both tomorrow morning.
Also, you're awesome dude.
No rush, just came with a few ideas recently.
I noticed json-patch
recently upgraded to 0.6.0, which is great (and I feel bad I let them do it, meant to contribute a PR myself).
Hah, you did! Perhaps not to hatch directly but the state of this crate would be in much worse shape without your contributions. You brought it up a few levels! :)
To be honest the unsafe for internal uses might be a bit overkill, I'm not 100% sure this is a great idea long term, but since it's an internal detail I think it's ok to experiment with.
Although a lot more inconvenient for us, some of our functions have invariants that have to be held externally, so they should be
unsafe fn
. This also makes it justifiable to expose them publicly (as then users can opt-in for manual checking of the invariants).Notable changes:
Pointer::new
as a public (but unsafe) constructor (now calledPointer::new_unchecked
). This gives users a way to bypass validation if they're sure they've got a valid string. Akin toString::from_utf8_unchecked
and family.PointerBuf::new_unchecked
as a new unsafe constructor, to matchPointer::new_unchecked
.Token::from_encoded_unchecked
unsafe. This one I didn't make public because I don't see much use for it. We may revisit this later.