Skip to content

release tagging: clippy 1.46 tag and rustc 1.46 tag diverge #5981

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

Open
matthiaskrgr opened this issue Aug 28, 2020 · 3 comments
Open

release tagging: clippy 1.46 tag and rustc 1.46 tag diverge #5981

matthiaskrgr opened this issue Aug 28, 2020 · 3 comments
Labels
A-infra Area: CI issues and issues that require full access for GitHub/CI

Comments

@matthiaskrgr
Copy link
Member

Now that clippy is contained inside the rustc repo as a subrepo, how do we do the release tagging?

I noticed that that the 1.46.0 tag inside the clippy repo points to c2c07fa

    Auto merge of #5740 - lzutao:unused-unused, r=flip1995

    Remove unused allowed unused attributes

    changelog: none

but when checking out the tag 1.46.0 of the rustc repo and cd-ing into the clippy subrepo, the last commit that touched clippy is 90f1d72

     Rollup merge of #72920 - oli-obk:const_transmute, r=RalfJung

    Stabilize `transmute` in constants and statics but not const fn

    cc #53605 (leaving issue open so we can add `transmute` to `const fn` later)

    Previous attempt: #64011

In short, the clippy 1.46.0 tag does not represent the rustc 1.46.0 tag. :/

I would expect that if I check out 1.46.0 inside the clippy repo I would get the clippy that was shipped with the rust release.

To make this happen I guess we need to do syncs both way shortly before the release to so that changes that were pushed into rustc are inside clippy and changes from clippy are inside rustc.

Should we redo the 1.46.0 tag inside the clippy repo somehow?

@matthiaskrgr matthiaskrgr added the A-infra Area: CI issues and issues that require full access for GitHub/CI label Aug 28, 2020
@flip1995
Copy link
Member

The different commits in rust-lang/rust and rust-lang/rust-clippy for the Clippy release come from the fact that commits to rustc can change Clippy.

The sync direction Clippy -> rustc (subtree pull) keeps the commit hashes as they are in Clippy. The sync direction rustc -> Clippy (subtree push) doesn't. This is because a commit to rustc can change for example a file in src/librustc_middle and in src/tools/clippy simultaneously, but only the changes to src/tools/clippy will be synced to Clippy. Therefore, the commit hashes cannot be the same, since they have differing content.

So we can do two things:

  1. (current) tag the latest Clippy commit that was synced into rustc. We can find this commit with the short and simple command:
    git log --oneline -- src/tools/clippy/ | grep -o "Merge commit '[a-f0-9]*' into .*" | head -1 | sed -e "s/Merge commit '\([a-f0-9]*\)' into .*/\1/g"
    
  2. Find the equivalent of the latest commit to src/tools/clippy (in rustc) in the rust-clippy repo and tag that commit. (I have no idea if we can find this commit with a script or if we would have to search for it by hand)
  3. ? I'm open to more and better ideas.

In both cases the latest commit in rustc and the tagged Clippy commit will diverge. In the second case the tagged commit in Clippy doesn't even exist in the history of the rustc release, which is why I decided to go for the first variant.

Since commits modifying Clippy in the rustc repo shouldn't include user facing changes, tagging a few commits too early shouldn't be that much of a problem, IMO.

This type of tagging was done since rust-1.45.0.

To make this happen I guess we need to do syncs both way shortly before the release

We definitely don't want to do this, since this has the potential to get bugs into beta without even being available in nightly for one day. @ebroto and me recently talked about the sync process (Clippy -> rustc) and he documented it here.

@matthiaskrgr
Copy link
Member Author

Right, I'm aware that the commits can't be the same.

I'm trying to visualize this a bit:

rustc:

commit R1 fix clippy test due to rustc change B
commit R2 sync clippy into rustc 
commit R3 add new "foo" lint

clippy:

commit C1 add new lint "bar"
commit C2 add new lint "foo"
commit C3 fix clippy test due to rustc change A

Right now I would try to "fix" the tag in the clippy repo to point to C2 (which is equivalent to R2 in the rustc repo)

Alternative idea:
The tag inside the rustc repo represents R1, but:
R1 (as child of R2) does not exist in the clippy repo.
To fix this, make a branch of the clippy repo at C2 (which represents R2 in the rustc repo), sync (rustc->clippy) R1 into that branch and make the branch tip the tag (branch can be deleted afterwards).
This way we have something that represents clippy state at the time of tagging even if it actually never occurred in the clippy repo.

@flip1995
Copy link
Member

Right now I would try to "fix" the tag in the clippy repo to point to C2 (which is equivalent to R2 in the rustc repo)

We're currently doing exactly that, but C2===R3, not R2.

To fix this, make a branch of the clippy repo at C2 (which represents R2 in the rustc repo), sync (rustc->clippy) R1 into that branch and make the branch tip the tag (branch can be deleted afterwards).

R2 also doesn't exist in Clippy. C2===R3. But if we sync R1 into a new branch, the commit hashes still won't match. This would just be a possibility how to implement 2. from my comment above:

# in rust-lang/rust:
git checkout 1.46.0
git subtree push -P ... clippy-remote rust-1.46.0
# in rust-lang/clippy:
git branch master --contains=rust-1.46.0 # should output "master", meaning, master contains this commit
# now HEAD of the rust-1.46.0 branch (C0) is the equivalent commit to R1, but C0!=R1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-infra Area: CI issues and issues that require full access for GitHub/CI
Projects
None yet
Development

No branches or pull requests

2 participants