Uh oh!
There was an error while loading. Please reload this page.
Add --extend-css option to rustdoc - #32230
Conversation
alexcrichton
commented
Mar 13, 2016
I would prefer we not land any new insta-stable options into rustdoc. We've already got infrastructure in the compiler for truly unstable options, and rustdoc should likely adopt a similar strategy. |
GuillaumeGomez
commented
Mar 13, 2016
"insta-stable"? "truly unstable"? Sorry but I don't understand these two points. Could you explain them please? (Or give me a link?) |
alexcrichton
commented
Mar 14, 2016
Yes, to clarify I mean:
|
GuillaumeGomez
commented
Mar 14, 2016
@alexcrichton: I updated the code. Does this check seems enough for you? |
alexcrichton
commented
Mar 15, 2016
No, the compiler has the ability to specify options with a stability level attached to them. The options are always parsed but any usage of an unstable option is gated. That's functionally what happens here but it's very brittle as it'd be tied to each option specifically. All of this is also with a grain of salt as well, as we still have yet to make a decision at all as to whether to allow custom css like this. I thought that in previous PRs we decided not to? |
GuillaumeGomez
commented
Mar 15, 2016
@alexcrichton: In the PR you're referring to, I tried to propose alternative style by providing css and to allow readers to switch between themes while reading the docs. This one is very different since it targets docs builders, and allow them to customize the css. I exposed the idea to @brson and he said it was ok (at least to open the PR). The thing I understood rust people didn't want was to change the official doc style. This one doesn't change it. PS: if this PR goes further, where can I find a "gated" option, so I can do the same for this one? |
brson
commented
Mar 15, 2016
@GuillaumeGomez it sounds like we need to add feature gating to rustdoc. Here's basically what we need to do:
Here's the equivalent code that deals with command-line feature gating in rustc. This is similar to the code you've previously added to make Sorry for the inconvenience. |
GuillaumeGomez
commented
Mar 15, 2016
Oh I see, I thought a full code suite was made for it. Thanks @brson! |
There was a problem hiding this comment.
Could the text here be "internal and debugging options" to more closely match rustc? -Z isn't just for the unstable-options flag (in theory).
| fn is_unstable_flag_enabled(nightly_build: bool, has_z_unstable_options: bool, | ||
| flag_name: &str) { | ||
| // check if unstable for --extend-css option | ||
| match if !nightly_build { |
There was a problem hiding this comment.
nit:
- maybe this could just be a
letinstead ofmatchand early return in theelsecase? - could this function be named
check_*? Withis_*I'd expect a bool return value.
There was a problem hiding this comment.
maybe this could just be a let instead of match and early return in the else case?
Good idea.
could this function be named check__? With is__ I'd expect a bool return value.
At first, it was supposed to. I'll rename it.
brson
commented
Mar 16, 2016
@GuillaumeGomez I'm going to have to discuss this with the tools team since I'm getting significant pushback about adding the feature to rustdoc. I'll have to get back to you, but Ill try to it soon. |
alexcrichton
commented
Mar 16, 2016
From a technical point of view I think that this also needs some refactoring. The compiler has support for directly attaching a stability level to a command line option, and this is just an ad-hoc check whenever a command line option is consumed. Additionally, this is essentially duplicating the infrastructure in the compiler for this feature, and ideally we would not duplicate any of it. |
GuillaumeGomez
commented
Mar 16, 2016
@alexcrichton: This is frustrating to stop new things to emerge because of such missing mechanisms. However I understand so I can only agree to your opinion. Would you prefer that I create (or extend opts?) a common code for this? |
nrc
commented
Mar 16, 2016
Do we have a stability policy for tools like rustdoc? I did not think that we offered stability guarantees of any kind for rustdoc. I guess maybe it is wrapped up in the fact that rustdoc is in the main repo, not the nursery or something? I don't think we've ever audited the existing options, maybe we should (quite likely I just missed it if we have though). Anyway, I'm strongly in favour of this PR. I guess it should be unstable, but I don't feel like stability for rustdoc is super-important (c.f., the compiler). |
alexcrichton
commented
Mar 17, 2016
It's also frustrating to have code duplication within the project which causes subtle bugs to emerge in the future because they're not behaving the same way or because one was fixed without the other. I would recommend refactoring whatever's in rustc so it's usable between both the compiler and rustdoc.
Perhaps not written down, but do we have one written down for rustc? I'm under the assumption that it's basically almost all entirely stable today. We did a brief audit of compiler flags before 1.0, but we just didn't really have the effort or time to do it for rustdoc as well. |
GuillaumeGomez
commented
Mar 17, 2016
@alexcrichton: Before doing anything, I prefer wait the end of the debate so I don't work for nothing. |
alexcrichton
commented
Mar 17, 2016
There seems to be enough support for this feature that we probably want to land it in some capacity, so if the unstable gating works robustly as the compiler does then this is likely ready to r+ |
GuillaumeGomez
commented
Mar 17, 2016
@alexcrichton: Do you want me to directly centralize this "feature" on this PR or do you prefer I open another one? |
alexcrichton
commented
Mar 18, 2016
Let's do it as part of this PR as it'll just otherwise conflict |
GuillaumeGomez
commented
Mar 20, 2016
@alexcrichton: Done. Is it what you had in mind? |
GuillaumeGomez
commented
Mar 22, 2016
Any news? |
bors
commented
Mar 23, 2016
☔ The latest upstream changes (presumably #32390) made this pull request unmergeable. Please resolve the merge conflicts. |
GuillaumeGomez
commented
Apr 4, 2016
So the code is now the same as the previous one, just moved from another place. |
alexcrichton
commented
Apr 5, 2016
@bors: r+ dff79e4e3a1e975011f1181e175b4e902c481809 |
bors
commented
Apr 5, 2016
🔒 Merge conflict |
alexcrichton
commented
Apr 5, 2016
@bors: r+ 3665ba08cf38585466b57f696efc434024b8b3f4 |
bors
commented
Apr 6, 2016
⌛ Testing commit 3665ba0 with merge 541a166... |
bors
commented
Apr 6, 2016
💔 Test failed - auto-mac-64-opt-rustbuild |
There was a problem hiding this comment.
I think this is redundant now that this is also in SharedContext?
There was a problem hiding this comment.
The issue comes from the fact that this option must be used in both Context and SharedContext. I tried to have it only in SharedContext but the code started to change way too much compared to the "gain".
There was a problem hiding this comment.
Can't you do cx.shared.css_file_extension?
There was a problem hiding this comment.
Oh, indeed. Modified too quickly.
GuillaumeGomez
commented
Apr 6, 2016
Re-updated to last rustdoc version. |
alexcrichton
commented
Apr 6, 2016
bors
commented
Apr 6, 2016
⌛ Testing commit 669edfa with merge a828124... |
bors
commented
Apr 6, 2016
💔 Test failed - auto-mac-32-opt |
GuillaumeGomez
commented
Apr 6, 2016
Why is there a line longer than 100 chars in |
alexcrichton
commented
Apr 6, 2016
@bors: retry On Wed, Apr 6, 2016 at 1:32 PM, Guillaume Gomez notifications@github.com
|
Fixes#32223
r? @brson