Skip to content

Publish a new release #5270

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
Closed
CreepySkeleton opened this issue Mar 5, 2020 · 15 comments
Closed

Publish a new release #5270

CreepySkeleton opened this issue Mar 5, 2020 · 15 comments

Comments

@CreepySkeleton
Copy link

Hey guys, it looks like there wasn't a release of clippy in a few months already. Would it be possible to publish a new version?
@matthiaskrgr
Copy link
Member

matthiaskrgr commented Mar 5, 2020 •
edited
Loading

Hi, clippy is no longer published to crates.io.

Nowadays clippy is distributed by rustup (which you might already use to get the rust compiler).
In this case, you can install clippy via rustup component add clippy.
rustup update will then update both, clippy and the compiler if updates are available for both.

@CreepySkeleton
Copy link
Author

What I meant was that the latest clippy shipped with cargo had been released few months ago:

$ cargo clippy -V
clippy 0.0.212 (69f99e74 2019-12-14)

But the most recent rustc was released a week ago

$ rustc -V
rustc 1.41.1 (f3e1a954d 2020-02-24)

Everything's up to date as far as I can tell:

$ rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: checking for self-updates

   stable-x86_64-pc-windows-msvc unchanged - rustc 1.41.1 (f3e1a954d 2020-02-24)
  nightly-x86_64-pc-windows-msvc unchanged - rustc 1.43.0-nightly (75cf41afb 2020-03-04)

info: cleaning up downloads & tmp directories

@flip1995
Copy link
Member

flip1995 commented Mar 5, 2020 •
edited
Loading

The Clippy version was not updated in the point release of rust 1.41.1, so it is still the 69f99e7 commit, as it was in rust 1.41.0.

Clippy has a 1.41.1 release: https://github.com/rust-lang/rust-clippy/releases/tag/rust-1.41.1

If you want a more recent Clippy, you can use the nightly or beta toolchain.

@flip1995 flip1995 closed this as completed Mar 5, 2020
@Cypher1
Copy link

Cypher1 commented Dec 21, 2021

Can someone link me to the issue where it was decided to not ship to crates.io anymore? I used to be able to build from source using cargo install and rustup doesn't support my platform

@flip1995
Copy link
Member

You can still install Clippy from source. For this see our documentation.

There's not a real issue about this. Since Clippy got distributed via rustup, publishing it on crates.io doesn't make sense for us. The PR where we stopped publishing is #3247

@Cypher1
Copy link

Cypher1 commented Dec 21, 2021

Sure, but before it was easy, now I'm going to have to do a multistep process because having two ways to install it was a boy odd? There's probably more to it than that but it's annoying when something that used to work stops working without a clear reason for the lack of support

@Cypher1
Copy link

Cypher1 commented Dec 21, 2021

It also looks like the rust-clippy build script only works with the nightly compiler, can you confirm this?

@matthiaskrgr
Copy link
Member

Yes, but you were never able to build "any" version of clippy with "any" version of the compiler I think.
Nightly clippy builds used to break all the time back then.

The nighty version that the repo is guaranteed to build with is set via the rust-toolchain file.

@Cypher1
Copy link

Cypher1 commented Dec 21, 2021

I've checked out rust-clippy's stable tag, removed the nightly only flags (as I don't have a nightly compiler), and now I'm directed to use rustup for get additional sources.
Is my only avenue forward (back to the workflow I had previously) to build significant chunks of rust from source?

Please don't understand me as saying it's wrong to tie clippy to rustup. I'm not, it might make sense for the project and most users. Still, I'd just like to know what benefit clippy gets from changing how it ships

@matthiaskrgr
Copy link
Member

Clippy is kind of tied to the compiler. Cippy asks the compiler for its representation of the code, runs some lints, returns the results back to the compiler and then rustc prints the lint warnings that we all love.

So clippy directly uses a bunch of rustcs compiler internal APIs/functions/data structures etc.
Since the compiler changes rapidly, this previously meant that clippys code needed to be updated continuously by the clippy team to match the rustc api (otherwise clippy would simply not compile).
Back at this time, clippy binary would be unavailable for days from nightly rustc from time to time.

At some point we got fed up and added a copy of clippy to the rustc source tree, so now when someone changes rustc code, they can fix the incompatibility with clippy at the same time, so that the rustc api and the in-source clippy stay in sync and clippy compiles stably all the time.

Every couple of weeks, the api compatibility fixes that went into the clippy-rustc are merged into this github repo and the new lints or fixes that were made to clippy in this repo are synced back into the rustc repo.
This can look like this: rust-lang/rust@f1a779c#diff-ecc74b126edfb289f95b6a04969f6adc10f10bbe207c2073ebf356fa1612a3c1

Inside this repo, after each sync from the rustc we pin the nightly to the rustc nightly that we synced from (with the rust-toolchain file) to make sure contributors can build and test clippy.

I hope this gives some rough overview, please correct me if I am wrong 🙂

@flip1995
Copy link
Member

flip1995 commented Dec 21, 2021 •
edited
Loading

So IIUC you only have a stable rustc and no rustup? I assume you have access to cargo? On what target are you trying to build Clippy? With that information I may be able to give you a better suggestion on how to move forward. Otherwise I can only to continue to make wild guesses.

If you're building for a target that doesn't have the rustc-dev component available, then building rustc from source together with Clippy might be the only way (./x.py build src/tools/clippy in rust-lang/rust).

@Cypher1
Copy link

Cypher1 commented Dec 21, 2021 via email

@flip1995
Copy link
Member

Thanks for the information! aarch64-linux-android is a Tier 2 platform without host tools, which means, that the rust project currently doesn't ship any tools and with that also doesn't ship rustc-dev, which is required to compile Clippy. So the only way to natively compile Clippy for aarch64-linux-android is to compile rustc itself and with that Clippy. You can do this in rust-lang/rust with ./x.py build src/tools/clippy.

This might take a while though. You may want to try to cross-compile Clippy. Out of interest I tried to do this and those are the steps that I came up with:

  1. Have access to a machine which has at least Tier 2 with host tools support and where the Android NDK is available
  2. Download the Android NDK: https://developer.android.com/ndk/downloads
    a. export PATH=/path/to/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH
  3. Install the aarch64-linux-android target with rustup target add aarch64-linux-android
  4. In the Clippy repo, run: cargo dev setup intellij --repo-path=/path/to/rust and move the added dependencies from cfg(NOT_A_PLATFORM) to normal deps.
  5. Add the following lines to .cargo/config.toml: 
    [target.aarch64-linux-android]
linker = "/path/to/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang"
  6. Build Clippy with RUSTC_INSTALL_BINDIR=bin CFG_RELEASE_CHANNEL=nightly CFG_RELEASE=1.59.0 cargo build --target=aarch64-linux-android --release (during linking it might look for -lgcc. You can work around this error by adding a libgcc.a textfile with the content INPUT(-lunwind) to /path/to/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android)

Note: It would also not help you, if Clippy would still be available on crates.io. The blocker is, that you don't have access to the rustc-dev component.

@Cypher1
Copy link

Cypher1 commented Dec 22, 2021 via email

@flip1995
Copy link
Member

flip1995 commented Dec 22, 2021 •
edited
Loading

I mean, that's kinda what being unsupported is, so it's a cost benefit analysis thing.

Yeah, you could make the case to add host tool support to aarch64-linux-android in rust-lang/rust. Though I don't know how much work that would be. Here's the policy for adding host tool support to a Tier 2 target: https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-2-with-host-tools

Totally understand if it's too costly to do, just galling for me that it used to work so nicely and now it seems out of reach.

It would surprise me if there would be any difference if we'd publish it on crates.io. "used to work so nicely" must be years ago, where all the rustc_* crates were still shipped in rust-std: rust-lang/rust#64823.

Thanks for the help though. Hope it hasn't been a drag to walk me through it all.

Not at all!

@ErikEverson ErikEverson mentioned this issue Apr 9, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@matthiaskrgr @Cypher1 @flip1995 @CreepySkeleton