Replace script_plugins with a clippy like rustc driver (named crown)#30508
Replace script_plugins with a clippy like rustc driver (named crown)#30508mrobinson merged 27 commits intoservo:masterfrom
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
| SHELL: /bin/bash | ||
| SCCACHE_GHA_ENABLED: "true" | ||
| RUSTC_WRAPPER: "sccache" | ||
| #RUSTC_WRAPPER: "sccache" |
There was a problem hiding this comment.
Perhaps this was left by mistake?
There was a problem hiding this comment.
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.
I would remove this line then, rather than leaving it commented out.
|
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 |
mrobinson
left a comment
There was a problem hiding this comment.
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
| SHELL: /bin/bash | ||
| SCCACHE_GHA_ENABLED: "true" | ||
| RUSTC_WRAPPER: "sccache" | ||
| #RUSTC_WRAPPER: "sccache" |
There was a problem hiding this comment.
I would remove this line then, rather than leaving it commented out.
| 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.
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.
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.
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.
This could work, but crown is run for every rustc invocation, which could slow down compilation.
There was a problem hiding this comment.
Maybe storing good rust version in env var would speed things up, but then we can have old data in env var.
|
Rebase |
| 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.
Please remove this change line since it's no longer needed after the rebase.
There was a problem hiding this comment.
I do not think so:
servo/.github/workflows/mac.yml
Line 139 in d10688b
target/${{ inputs.profile }}/*.dylib is only matched with script_plugin.dylib and now that it does not exist this step fails.
| env: | ||
| RUSTC: "rustc" |
There was a problem hiding this comment.
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.
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 <mrobinson@igalia.com> * 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 <16504129+sagudev@users.noreply.github.com> * Proper test types * Ignore tidy on crown/tests --------- Co-authored-by: Martin Robinson <mrobinson@igalia.com>
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 <mukilan@igalia.com>
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 <mukilan@igalia.com>
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 <mukilan@igalia.com>
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
scriptcrate we get this warning:Sccache does not work when using crown, but that is sccache issue that I am actively working on.
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors