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.

Sign up for GitHub

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

Jump to bottom

Fix nested arrays (by reworking array handling) - backport #486

Merged
merged 4 commits into from
Nov 9, 2023
Merged

Fix nested arrays (by reworking array handling) - backport #486

merged 4 commits into from
Nov 9, 2023

Conversation

ijackson
Copy link
Contributor

Backport of #465 to 0.13.x branch. Fixes #464 there.

@matthiasbeyer
Copy link
Member

Please re-do the commits with the -x flag on git-cherry-pick (as noted here) so that the backported commits refer to the original ones.

@ijackson ijackson force-pushed the nested-array-backport branch from 9f2da44 to e6d85cc Compare October 23, 2023 17:11
@ijackson
Copy link
Contributor Author

ijackson commented Oct 23, 2023 •
edited
Loading

Please re-do the commits with the -x flag on git-cherry-pick (as noted here) so that the backported commits refer to the original ones.

Ah sorry, didn't see that comment. FTR, I did:

for f in `git-rev-list --reverse --topo-order nested-array~4..nested-array`; do echo git cherry-pick -x $f; done | sh -xe

@matthiasbeyer
Copy link
Member 

for f in `git-rev-list --reverse --topo-order nested-array~4..nested-array`; do echo git cherry-pick -x $f; done | sh -xe

The following would have been sufficient:

git cherry-pick -sx $(git merge-base master^1 master^2)..master^2
Explanation of the above command Explanation: The above means cherry-pick the changes:
  • from the merge base of the commit to the left of current master and the commit to the right of current master (the last commit of the previously merged PR)
  • to the commit to the right of current master (the last commit of the previously merged PR)

You can replace the git cherry-pick -sx with git log --oneline and you'll see that this is exactly the range you want to pick.

But no worries! Log looks good now, let's see what CI tells us!

It seems that we have to bump the MSRV for the next 0.13.x release ... I don't like that but I don't see a better way, tbh.
I think I'll do that and rebase this PR then. No need to worry for you!

@ijackson
Copy link
Contributor Author

I think we could fix this on the 0.13 branch by committing a suitable Cargo.lock. Would you like me to do that?

@ijackson
Copy link
Contributor Author

It seems that we have to bump the MSRV for the next 0.13.x release ... I don't like that but I don't see a better way, tbh. I think I'll do that and rebase this PR then. No need to worry for you!

Please let me have a go at fixing it with a Cargo.lock instead? I will try that tomorrow; it's getting rather late for me here now.

@matthiasbeyer
Copy link
Member

matthiasbeyer commented Oct 23, 2023 •
edited
Loading

Please let me have a go at fixing it with a Cargo.lock instead? I will try that tomorrow; it's getting rather late for me here now.

Yes, feel free to try. Although I am not sure about whether that would help, as downstream might still run into the issue that they have a new log crate version (for example) but an compiler too old for that crate version.

But I see where you're going. I'll stop my efforts for the MSRV update on the release branch (#487) now!

Have a good night! 🦉

@ijackson
Copy link
Contributor Author

I have succeeded, by providing a Cargo.lock. I will tidy up my branch and make an MR of it.

@ijackson
ser: sequences: Centralise
319a9e2 
Have all the various versions of sequences (arrays and various forms
of tuple) all go via ser::SerializeSeq.

This reduces some duplication.  And, we're about to change the
implementation.

Signed-off-by: Ian Jackson <[email protected]>
(cherry picked from commit ed6a3c9)
Signed-off-by: Ian Jackson <[email protected]>
@ijackson
ser: sequences: Introduce SeqSerializer newtype
43ac661 
We're going to want to do something more complicated.

In particular, to handle nested arrays properly, we need to do some
work at the start and end of each array.

The `new` and (inherent) `end` methods of this newtype is where that
work will be done.

Signed-off-by: Ian Jackson <[email protected]>
(cherry picked from commit 147e6c7)
Signed-off-by: Ian Jackson <[email protected]>
@ijackson
ser: sequences: Rework, fixing handling of nested arrays
9bed600 
Change the representation of our "current location".  Previously it
was a list of increasingly-long full paths, but excepting the putative
final array index.

Now we just record the individual elements. and assemble the whole
path just before calling .set().  This saves a little memory on the
whole since the entries in keys are now a bit shorter.

It is much less confusing.  (There are perhaps still further
opportunities to use Rust's type system to better advantage to
eliminuate opportunities for bugs.)

Arrays that appear other than at the top level are now handled
correctly.  This includes nested arrays, and arrays containing
structs, etc.

Signed-off-by: Ian Jackson <[email protected]>
(cherry picked from commit 831102f)
Signed-off-by: Ian Jackson <[email protected]>
@ijackson
ser: sequences: Test a more comprehensive round-trip
eb46fd6 
Signed-off-by: Ian Jackson <[email protected]>
(cherry picked from commit aa63d2d)
Signed-off-by: Ian Jackson <[email protected]>
@ijackson ijackson force-pushed the nested-array-backport branch from e6d85cc to eb46fd6 Compare November 7, 2023 11:19
@ijackson
Copy link
Contributor Author

ijackson commented Nov 7, 2023

I've rebased this to pick up the CI fix from #496

@matthiasbeyer
Copy link
Member

I am on vacation until late tomorrow. I hope I can get back to this as soon as possible.

matthiasbeyer
matthiasbeyer approved these changes Nov 9, 2023
View reviewed changes
Copy link
Member

@matthiasbeyer matthiasbeyer left a comment

Choose a reason for hiding this comment

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

As all commits were picked from approved PRs, I don't see why I shouldn't approve this as well 😆

@matthiasbeyer matthiasbeyer merged commit db754f5 into rust-cli:release-0.13.x Nov 9, 2023
14 checks passed
@ijackson ijackson mentioned this pull request Nov 21, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@matthiasbeyer matthiasbeyer matthiasbeyer approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ijackson @matthiasbeyer