Added a bare-bones eslint config (removing jslint)
This change removes the small bit of jslint config, replacing it
with eslint. I've currently configured eslint to mostly only report
the more serious of lints, although there are still some style nits
turned on.
Eslint better supports modern js, and will be a good pre-TypeScript code
quality aid.
Install eslint with `npm install -g eslint`. Run with `eslint html/static/*.js`,
or let your IDE do it. This requires no build step.
Upcoming changes will start fixing identified bugs and other lints (mostly unused and var redef issues).
Fix invalid line number match
If a code line is longer than the width, it then gets to the next line making the line number not matching it anymore.
r? @QuietMisdreavus
This change removes the small bit of jslint config, replacing it
with eslint. I've currently configured eslint to mostly only report
the more serious of lints, although there are still some style nits
turned on.
Upcoming changes will start fixing lints.
set to zero meant that the nested list was squished up against
subsequent list items/paragraphs
this changes the bottom margin to .6em, same as for paragraphs
an example demonstrating the difference with screenshots is given in the
pull request
This is a (much) more constrained version of #54772 that also aims at
improving the situation in #34681. It removes any font specifications
that are not the "official" rustdoc font, and instead relies on the
browser to provide the fallback font if the official on is not
available. On Linux systems, this is particularly important, as fonts
like Helvetica, Arial, and Times often look pretty bad since they're
pulled from extracted MS fonts. A specification like `serif` or
`sans-serif` lets the browser instead choose a good font.
1. Extract the tests for whether or not we have workable localStorage out into
a helper method, so it can be more easily reused
2. Use it in getCurrentValue() too, for the same reasons, as suggested in code
review
If the user's cookie/persistent storage setting forbid access to localStorage,
catch the exception and abort the access.
Currently, attempting to use the expand/contract links at the top of the page
for structs/consts/etc. fails due to an unhandled error while accessing
localStorage, if such access is forbidden, as the exception from the failed
access propagates all the way out, interrupting the expand/contract. Instead, I
would like to degrade gracefully; the access won't happen (the collapse/expand
state won't get persisted) but the actual expanding/contracting of the item
will go on to succeed.
Fixes#55079
rustdoc: give proc-macros their own pages
related to https://github.com/rust-lang/rust/issues/49553 but i don't think it'll fix it
Currently, rustdoc doesn't expose proc-macros all that well. In the source crate, only their definition function is exposed, but when re-exported, they're treated as a macro! This is an awkward situation in all accounts. This PR checks functions to see whether they have any of `#[proc_macro]`, `#[proc_macro_attribute]`, or `#[proc_macro_derive]`, and exposes them as macros instead. In addition, attributes and derives are exposed differently than other macros, getting their own item-type, CSS class, and module heading.
Function-like proc-macros are lumped in with `macro_rules!` macros, but they get a different declaration block (i'm open to tweaking this, it's just what i thought of given how function-proc-macros operate):
Proc-macro attributes and derives get their own pages, with a representative declaration block. Derive macros also show off their helper attributes:
There's one wrinkle which this PR doesn't address, which is why i didn't mark this as fixing the linked issue. Currently, proc-macros don't expose their attributes or source span across crates, so while rustdoc knows they exist, that's about all the information it gets. This leads to an "inlined" macro that has absolutely no docs on it, and no `[src]` link to show you where it was declared.
The way i got around it was to keep proc-macro re-export disabled, since we do get enough information across crates to properly link to the source page:
Until we can get a proc-macro's docs (and ideally also its source span) across crates, i believe this is the best way forward.
