-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Test themes #47761
Test themes #47761
Conversation
|
ab0eb13
to
6b716a6
Compare
☔ The latest upstream changes (presumably #47748) made this pull request unmergeable. Please resolve the merge conflicts. |
src/bootstrap/check.rs
Outdated
cmd.args(&["src/tools/rustdoc-themes/test-themes.py", rustdoc.to_str().unwrap()]); | ||
cmd.env("RUSTC_STAGE", self.compiler.stage.to_string()) | ||
.env("RUSTC_SYSROOT", builder.sysroot(self.compiler)) | ||
.env("RUSTDOC_LIBDIR", builder.sysroot_libdir(self.compiler, builder.build.build)) |
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 should probably be self.compiler.host
as the second argument.
src/bootstrap/check.rs
Outdated
} | ||
|
||
fn run(self, builder: &Builder) { | ||
let rustdoc = builder.out.join("bootstrap/debug/rustdoc"); |
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 should be a call to builder.rustdoc
. Otherwise it may not have been built yet.
src/bootstrap/check.rs
Outdated
|
||
fn run(self, builder: &Builder) { | ||
let rustdoc = builder.out.join("bootstrap/debug/rustdoc"); | ||
let mut cmd = Command::new(builder.config.python.clone().unwrap()); |
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 call expect("python not defined")
or something similar.
src/librustdoc/theme.rs
Outdated
pathes.iter().cloned().collect() | ||
} | ||
|
||
pub fn load_css_pathes(v: &[u8]) -> CssPath { |
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.
nit: paths
print_err('No theme found in "{}"...'.format(THEME_DIR_PATH)) | ||
return 1 | ||
args = [rustdoc_bin, '-Z', 'unstable-options', '--theme-checker'] | ||
args.extend(themes) |
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.
So it's not super clear to me why we need this script instead of inlining this logic into rustbuild. That would be my preference...
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.
It's simpler and more flexible from my point of view.
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.
How is it better to have this in a python file vs having it in rustbuild? I prefer that we have as much as possible in rustbuild and in Rust. This is out-of-band and nearly impossible to find unless you know about 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'm going to side with @Mark-Simulacrum here. The fact that this script is in Python doesn't add anything over just having the logic inline with its call in rustbuild. It's literally just "for all the .css files in this folder except main.css
, call rustdoc with these extra flags and that file". Python just seems to be invoked here for the directory-crawling aspect? You can get close enough with std::fs::read_dir
, IMO.
819679f
to
5083535
Compare
@Mark-Simulacrum: Updated as you suggested. |
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'm a little worried that this effectively contains a homebrew CSS parser. Would including a separate crate for that be too much of a problem?
src/librustdoc/lib.rs
Outdated
print!(" - Checking \"{}\"...", theme_file); | ||
let (success, differences) = theme::test_theme_against(theme_file, &paths); | ||
if !differences.is_empty() || !success { | ||
eprintln!(" FAILED"); |
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'm a little alarmed that the "Checking {}
" and "FAILED" are sent to different output streams. Is this standard practice elsewhere?
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.
Not sure. I'll give it a look.
src/librustdoc/theme.rs
Outdated
d {} | ||
"#; | ||
let paths = load_css_paths(text.as_bytes()); | ||
assert!(paths.children.get(&CssPath::new("a b c d".to_owned())).is_some()); |
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.
.get(..).is_some()
is the same as .contains(..)
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.
Oh indeed, thanks!
Not sure it's worth it. I mean, it's quite small and strongly integrated into rustdoc. This "CSS parser" is very basic and only get css-selectors by parsing comments and blocks. |
d8eb2f3
to
1cac26d
Compare
So what should we do about this PR? We need it quickly if we want to add other themes (and to check those provided by users when they build docs with their own theme). |
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 like the python script removed, and then I think I'm mostly okay with landing this.
pub children: HashSet<CssPath>, | ||
} | ||
|
||
// This PartialEq implementation IS NOT COMMUTATIVE!!! |
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 seems bad. Perhaps we shouldn't have a PartialEq (and much less Eq) impl and instead just have a method that does this? I'm somewhat concerned that we're going to run into problems with stdlib's HashSet etc where things oddly fail to work.
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 appreciated to be able to use ==
. 😞 I can do it in a method, but the basic issue will be the same: the check won't be commutative. We want to check that the second object implements all the first one's rules. If it has more, we don't care. We don't require an absolute equality. That's why I did it like this.
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.
Hm. Yeah, I'd probably prefer a method (with a name like contains_rules
or something), but I guess I don't care too much. Not a blocking concern, probably.
} | ||
} | ||
|
||
impl Hash for CssPath { |
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 feels derivable?
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 because to have Hash
implemented for CssPath
, you need to have it implemented on CssPath
. :p
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.
Ah. Okay.
@Mark-Simulacrum: I'd prefer to keep the python script if possible for potential evolutions. For now it's quite simple but I have a few others things that'll be required later on with some new features. Having to update the builder rust code instead of having a small outside python script doesn't seem to be a very good idea from my point of view. |
I guess I'm failing to see why editing the Rust code is easier/better than the Python code. But I feel like we're somewhat talking past each other -- I don't think we've brought up any new arguments in this discussion for a while. Could we perhaps move the python code into Rust, and if later down the line we add additional features to it that make it easier to implement in Python, we can move it over again? I guess my main point here is that while Python may be easier for some (including perhaps you!) to edit and understand, I find Rust much easier to understand (and expect that to be true for the majority of Rust contributors). Does that help explain my reasoning for why it seems better to keep as much code as possible in Rust? |
In my limited experience, projects with multiple languages tend to be more work to maintain in the long run... IMHO, it would be good to keep everything in Rust... |
Hum ok... So should I just replace the python code in rust or should I move this code directly into the builder? |
Since you told me you want to extend this script in the future, i think it will be fine to just replace it with rust, without integrating it into rustbuild. |
Integrating it as a function in rustbuild would be easier as you don't have to worry about compiling it. |
@Mark-Simulacrum: My only concern with this is that you don't know this test exists unless you wrote it. I like having the match between the test runner and a folder. |
1cac26d
to
4c14d22
Compare
I converted the python script into rust. |
4c14d22
to
f4be404
Compare
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'm mostly happy with this. r=me if you remove host
in failure of just using compiler.host
, otherwise I'd like to review again. Thanks for bearing with me!
src/bootstrap/test.rs
Outdated
#[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] | ||
pub struct RustdocTheme { | ||
pub compiler: Compiler, | ||
pub host: Interned<String>, |
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 not compiler.host
? It should be afaict... or it should be named differently, or have some documentation. Right now this seems likely to be brittle in some configurations.
pub children: HashSet<CssPath>, | ||
} | ||
|
||
// This PartialEq implementation IS NOT COMMUTATIVE!!! |
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.
Hm. Yeah, I'd probably prefer a method (with a name like contains_rules
or something), but I guess I don't care too much. Not a blocking concern, probably.
} | ||
} | ||
|
||
impl Hash for CssPath { |
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.
Ah. Okay.
f4be404
to
ae657f5
Compare
Updated. |
ae657f5
to
dec9fab
Compare
@bors r=Mark-Simulacrum |
📌 Commit dec9fab has been approved by |
💔 Test failed - status-appveyor |
@bors retry 3 hour timeout in |
💔 Test failed - status-appveyor |
@bors retry (3 hour timeout, This PR keeps timing out in some unconventional places. |
All rust test chain is weird. |
☀️ Test successful - status-appveyor, status-travis |
r? @QuietMisdreavus
cc @Mark-Simulacrum