-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Conversation
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)]
| ^^^^^^^^^^^^^ |
@bors-servo try |
🔨 Triggering try run (#6440698317) with platform=all and layout=all |
.github/workflows/linux.yml
Outdated
@@ -45,7 +45,7 @@ env: | |||
RUST_BACKTRACE: 1 | |||
SHELL: /bin/bash | |||
SCCACHE_GHA_ENABLED: "true" | |||
RUSTC_WRAPPER: "sccache" | |||
#RUSTC_WRAPPER: "sccache" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
I am getting this on mac:
Maybe there is some silent fail in mach and things still continue to roll after it. |
I fixed mac build, all real dylibs were under target/release/libs/*dylibs Sccache is still disabled. |
Rebased for new nightly |
There was a problem hiding this 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.
.github/workflows/linux.yml
Outdated
@@ -45,7 +45,7 @@ env: | |||
RUST_BACKTRACE: 1 | |||
SHELL: /bin/bash | |||
SCCACHE_GHA_ENABLED: "true" | |||
RUSTC_WRAPPER: "sccache" | |||
#RUSTC_WRAPPER: "sccache" |
There was a problem hiding this comment.
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.
python/servo/platform/base.py
Outdated
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 | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
servo/.github/workflows/mac.yml
Line 139 in d10688b
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.
.github/workflows/windows.yml
Outdated
env: | ||
RUSTC: "rustc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this necessary?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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!
🔨 Triggering try run (#7059079398) with platforms=windows and layout=none |
|
🔨 Triggering try run (#7059184213) with platforms=windows and layout=none |
|
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 |
…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]>
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.
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.
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.
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]>
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]>
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]>
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.
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: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