Replace script_plugins with a clippy like rustc driver (named crown) by sagudev · Pull Request #30508

Replace script_plugins with a clippy like rustc driver (named crown) by sagudev · Pull Request #30508 · servo/servo

mentioned this pull request

Oct 6, 2023

sagudev marked this pull request as ready for review

October 7, 2023 10:31

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

mrobinson added this pull request to the merge queue

Dec 1, 2023

holmes-software pushed a commit to holmes-software/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 <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>

delan mentioned this pull request

Dec 6, 2023

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

mukilan added a commit to mukilan/servo that referenced this pull request

May 21, 2024

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.