Skip to content

Replace script_plugins with a clippy like rustc driver (named crown) #30508

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

Merged
merged 27 commits into from
Dec 1, 2023

Conversation

sagudev
Copy link
Member

@sagudev sagudev commented Oct 6, 2023

Required by rust-lang/rust#116412, modeled after https://github.com/Rust-for-Linux/klint.

If crown is not used in compilation of script crate we get this warning:

warning: unknown lint: `crown_is_not_used`
  --> components/script/lib.rs:16:8
   |
16 | #[deny(crown_is_not_used)]
   |        ^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> components/script/lib.rs:15:8
   |
15 | #[warn(unknown_lints)]
   |        ^^^^^^^^^^^^^

Sccache does not work when using crown, but that is sccache issue that I am actively working on.


  • ./mach build -d does not report any errors
  • ./mach test-tidy does not report any errors
  • There are tests for these changes

@sagudev
Copy link
Member Author

sagudev commented Oct 6, 2023

If crown is not used we get this warning:

warning: unknown lint: `crown_is_not_used`
  --> components/script/lib.rs:16:8
   |
16 | #[deny(crown_is_not_used)]
   |        ^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> components/script/lib.rs:15:8
   |
15 | #[warn(unknown_lints)]
   |        ^^^^^^^^^^^^^

@sagudev sagudev marked this pull request as ready for review October 7, 2023 10:31
@sagudev
Copy link
Member Author

sagudev commented Oct 7, 2023

@bors-servo try

@github-actions
Copy link

github-actions bot commented Oct 7, 2023

🔨 Triggering try run (#6440698317) with platform=all and layout=all

@@ -45,7 +45,7 @@ env:
RUST_BACKTRACE: 1
SHELL: /bin/bash
SCCACHE_GHA_ENABLED: "true"
RUSTC_WRAPPER: "sccache"
#RUSTC_WRAPPER: "sccache"
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps this was left by mistake?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, sccache issue is still not resolved, but I have a fix PR maybe we can use it.

Copy link
Member

Choose a reason for hiding this comment

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

I would remove this line then, rather than leaving it commented out.

Copy link
Member

Choose a reason for hiding this comment

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

Let's remove this for now.

@sagudev
Copy link
Member Author

sagudev commented Oct 10, 2023

I am getting this on mac:

gtar: target/release/*.dylib: Cannot stat: No such file or directory

Maybe there is some silent fail in mach and things still continue to roll after it.

@sagudev
Copy link
Member Author

sagudev commented Oct 31, 2023

I fixed mac build, all real dylibs were under target/release/libs/*dylibs
only dylib under target/release is libscript_plugins.dylib that was used by rustc during compilation of script crate.

Sccache is still disabled.

@sagudev sagudev requested a review from mrobinson October 31, 2023 09:39
@sagudev
Copy link
Member Author

sagudev commented Nov 2, 2023

Rebased for new nightly

@mrobinson mrobinson changed the title Replace script_plugins with crown (clippy like rustc driver) Replace script_plugins with a clippy like rustc driver (named crown) Nov 17, 2023
Copy link
Member

@mrobinson mrobinson left a comment

Choose a reason for hiding this comment

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

This is a really nice effort. There is a bit more work to do here, but this is a great start.

@@ -45,7 +45,7 @@ env:
RUST_BACKTRACE: 1
SHELL: /bin/bash
SCCACHE_GHA_ENABLED: "true"
RUSTC_WRAPPER: "sccache"
#RUSTC_WRAPPER: "sccache"
Copy link
Member

Choose a reason for hiding this comment

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

I would remove this line then, rather than leaving it commented out.

Comment on lines 116 to 124
def install_crown(self, force: bool) -> bool:
if subprocess.call(["cargo", "install", "--path", "support/crown"],
stdout=subprocess.PIPE, stderr=subprocess.PIPE) != 0:
raise EnvironmentError("Installation of crown failed.")

return True

Copy link
Member

Choose a reason for hiding this comment

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

There's an issue here which is that updates to crown won't be automatically installed when building.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's why it's always forced. It would be nice if we could be more smart about it, but I do not have any idea how.

Copy link
Member

@mrobinson mrobinson Nov 17, 2023

Choose a reason for hiding this comment

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

Perhaps when crown starts it could check a value in the workspace Cargo.toml which specifies the minimum version. If it is less than the current version it could emit an error and request running ./mach bootstrap again. ./mach bootstrap could always try to update to the latest version of `crown.

Copy link
Member Author

Choose a reason for hiding this comment

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

This could work, but crown is run for every rustc invocation, which could slow down compilation.

Copy link
Member Author

@sagudev sagudev Nov 17, 2023

Choose a reason for hiding this comment

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

Maybe storing good rust version in env var would speed things up, but then we can have old data in env var.

@sagudev
Copy link
Member Author

sagudev commented Nov 17, 2023

Rebase

@@ -121,7 +121,7 @@ jobs:
NIGHTLY_REPO_TOKEN: ${{ secrets.NIGHTLY_REPO_TOKEN }}
NIGHTLY_REPO: ${{ github.repository_owner }}/servo-nightly-builds
- name: Build package for target
run: gtar -czf target.tar.gz target/${{ inputs.profile }}/servo target/${{ inputs.profile }}/*.dylib target/${{ inputs.profile }}/lib/*.dylib resources
run: gtar -czf target.tar.gz target/${{ inputs.profile }}/servo target/${{ inputs.profile }}/lib/*.dylib resources
Copy link
Member

Choose a reason for hiding this comment

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

Please remove this change line since it's no longer needed after the rebase.

Copy link
Member Author

Choose a reason for hiding this comment

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

I do not think so:

run: gtar -czf target.tar.gz target/${{ inputs.profile }}/servo target/${{ inputs.profile }}/*.dylib target/${{ inputs.profile }}/lib/*.dylib resources

target/${{ inputs.profile }}/*.dylib is only matched with script_plugin.dylib and now that it does not exist this step fails.

Comment on lines 76 to 77
env:
RUSTC: "rustc"
Copy link
Member

Choose a reason for hiding this comment

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

Why is this necessary?

Copy link
Member Author

Choose a reason for hiding this comment

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

when doing cargo install --path support/crown we need to override RUSTC back to rustc otherwise cargo would use RUSTC=crown from .cargo/config.toml (we install crown without already having crown).

Copy link
Member

Choose a reason for hiding this comment

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

I think this should probably have a comment explaining this. It's a bit confusing otherwise. Thanks!

@sagudev sagudev added the T-windows Do a try run on Windows label Dec 1, 2023
@github-actions github-actions bot removed the T-windows Do a try run on Windows label Dec 1, 2023
Copy link

github-actions bot commented Dec 1, 2023

🔨 Triggering try run (#7059079398) with platforms=windows and layout=none

Copy link

github-actions bot commented Dec 1, 2023

⚠️ Try run (#7059079398) failed.

@sagudev sagudev added the T-windows Do a try run on Windows label Dec 1, 2023
@github-actions github-actions bot removed the T-windows Do a try run on Windows label Dec 1, 2023
Copy link

github-actions bot commented Dec 1, 2023

🔨 Triggering try run (#7059184213) with platforms=windows and layout=none

Copy link

github-actions bot commented Dec 1, 2023

⚠️ Try run (#7059184213) failed.

@sagudev
Copy link
Member Author

sagudev commented Dec 1, 2023

⚠️ Try run (#7059184213) failed.

I always forgot that CI changes are not testable with this, but it works on windows for me: https://github.com/sagudev/cargo-crown/actions/runs/7059052531

@sagudev sagudev requested a review from mrobinson December 1, 2023 11:13
@mrobinson mrobinson added this pull request to the merge queue Dec 1, 2023
Merged via the queue into servo:master with commit 604979e Dec 1, 2023
joshua-holmes pushed a commit to joshua-holmes/servo that referenced this pull request Dec 5, 2023
…ervo#30508)

* Remove script_plugins

* Use crown instead of script_plugins

* crown_is_not_used

* Use crown in command base

* bootstrap crown

* tidy happy

* disable sccache

* Bring crown in tree

* Install crown from tree

* fix windows ci

* fix warning

* fix mac

libscript_plugins.dylib is not available anymore

* Update components/script/lib.rs

Co-authored-by: Martin Robinson <[email protected]>

* Update for nightly-2023-03-18

Mostly just based off servo#30630

* Always install crown

it's slow only when there is new version

* Run crown test with `mach test-unit`

* Small fixups; better trace_in_no_trace tests

* Better doc

* crown in config.toml

* Fix tidy for real

* no sccache on rustc_wrapper

* document rustc overrides

* fixup of compiletest

* Make a few minor comment adjustments

* Fix a typo in python/servo/platform/base.py

Co-authored-by: Samson <[email protected]>

* Proper test types

* Ignore tidy on crown/tests

---------

Co-authored-by: Martin Robinson <[email protected]>
weihanglo added a commit to weihanglo/cargo that referenced this pull request Feb 20, 2024
Copy from <rust-lang#10469 (comment)>:

> I've never been entirely clear why it does this. rust-lang#4006 didn't really
> explain why it added the corresponding host_dylib_path. I can't envision
> a scenario where it matters. I think compiler plugins and proc-macros
> should load just fine, since libstd.so should already be loaded by the
> compiler. Also, rustc uses rpath these days, and on Windows libstd.so is
> placed in the bin directory which will be searched first anyways.
>
> On balance, I think it should be safe to just remove sysroot_host_libdir.
> I can't come up with a scenario where it matters, at least on
> windows/macos/linux. One issue is that this is most likely to affect
> plugins, but those are deprecated and I think only Servo was the real
> holdout. A concern is that nobody is going to test this use case before
> it hits stable.

Also,

* compiler plugins were removed rust-lang/rust#116412
* servo has moved off from plugins: servo/servo#30508

So should generally be fine.
weihanglo added a commit to weihanglo/cargo that referenced this pull request Feb 20, 2024
Copy from <rust-lang#10469 (comment)>:

> I've never been entirely clear why it does this. rust-lang#4006 didn't really
> explain why it added the corresponding host_dylib_path. I can't envision
> a scenario where it matters. I think compiler plugins and proc-macros
> should load just fine, since libstd.so should already be loaded by the
> compiler. Also, rustc uses rpath these days, and on Windows libstd.so is
> placed in the bin directory which will be searched first anyways.
>
> On balance, I think it should be safe to just remove sysroot_host_libdir.
> I can't come up with a scenario where it matters, at least on
> windows/macos/linux. One issue is that this is most likely to affect
> plugins, but those are deprecated and I think only Servo was the real
> holdout. A concern is that nobody is going to test this use case before
> it hits stable.

Also,

* compiler plugins were removed rust-lang/rust#116412
* servo has moved off from plugins: servo/servo#30508

So should generally be fine.
stupendoussuperpowers pushed a commit to stupendoussuperpowers/cargo that referenced this pull request Feb 28, 2024
Copy from <rust-lang#10469 (comment)>:

> I've never been entirely clear why it does this. rust-lang#4006 didn't really
> explain why it added the corresponding host_dylib_path. I can't envision
> a scenario where it matters. I think compiler plugins and proc-macros
> should load just fine, since libstd.so should already be loaded by the
> compiler. Also, rustc uses rpath these days, and on Windows libstd.so is
> placed in the bin directory which will be searched first anyways.
>
> On balance, I think it should be safe to just remove sysroot_host_libdir.
> I can't come up with a scenario where it matters, at least on
> windows/macos/linux. One issue is that this is most likely to affect
> plugins, but those are deprecated and I think only Servo was the real
> holdout. A concern is that nobody is going to test this use case before
> it hits stable.

Also,

* compiler plugins were removed rust-lang/rust#116412
* servo has moved off from plugins: servo/servo#30508

So should generally be fine.
mukilan added a commit to mukilan/servo that referenced this pull request May 21, 2024
This was previously disabled in servo#30508 due to sccache not
working well with crown. The sccache issue (mozilla/sccache#861)
linked in that PR is now closed and [testing][1] on my fork also
seems to indicated we should be able to turn on sccache again.

[1]: https://github.com/mukilan/servo/actions/runs/9154196647

Signed-off-by: Mukilan Thiyagarajan <[email protected]>
mukilan added a commit to mukilan/servo that referenced this pull request May 21, 2024
This was previously disabled in servo#30508 due to sccache not
working well with crown. The sccache issue (mozilla/sccache#861)
linked in that PR is now closed and [testing][1] on my fork also
seems to indicated we should be able to turn on sccache again.

[1]: https://github.com/mukilan/servo/actions/runs/9154196647

Signed-off-by: Mukilan Thiyagarajan <[email protected]>
github-merge-queue bot pushed a commit that referenced this pull request May 21, 2024
This was previously disabled in #30508 due to sccache not
working well with crown. The sccache issue (mozilla/sccache#861)
linked in that PR is now closed and [testing][1] on my fork also
seems to indicated we should be able to turn on sccache again.

[1]: https://github.com/mukilan/servo/actions/runs/9154196647

Signed-off-by: Mukilan Thiyagarajan <[email protected]>
charmitro pushed a commit to charmitro/cargo that referenced this pull request Sep 13, 2024
Copy from <rust-lang#10469 (comment)>:

> I've never been entirely clear why it does this. rust-lang#4006 didn't really
> explain why it added the corresponding host_dylib_path. I can't envision
> a scenario where it matters. I think compiler plugins and proc-macros
> should load just fine, since libstd.so should already be loaded by the
> compiler. Also, rustc uses rpath these days, and on Windows libstd.so is
> placed in the bin directory which will be searched first anyways.
>
> On balance, I think it should be safe to just remove sysroot_host_libdir.
> I can't come up with a scenario where it matters, at least on
> windows/macos/linux. One issue is that this is most likely to affect
> plugins, but those are deprecated and I think only Servo was the real
> holdout. A concern is that nobody is going to test this use case before
> it hits stable.

Also,

* compiler plugins were removed rust-lang/rust#116412
* servo has moved off from plugins: servo/servo#30508

So should generally be fine.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants