| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #55001, #54744
Previously, SelectionContext would unconditionally cache the selection
result for an obligation. This worked fine for most users of
SelectionContext, but it caused an issue when used by Rustdoc's blanket
impl finder.
The issue occured when SelectionContext chose a ParamCandidate which
contained inference variables. Since inference variables can change
between calls to select(), it's not safe to cache the selection result -
the chosen candidate might not be applicable for future results, leading
to an ICE when we try to run confirmation.
This commit prevents SelectionContext from caching any ParamCandidate
that contains inference variables. This should always be completely
safe, as trait selection should never depend on a particular result
being cached.
I've also added some extra debug!() statements, which I found helpful in
tracking down this bug.
|
|
Give each PathSegment a NodeId
Store a resolved def on hir::PathSegment
save-analysis: remove hacky, unnecessary code now that we have spans for every ident
dump data for prefix path segments
dump refs for path segments in save-analysis
Requires adding path segments to the hir map
Fix tests and rustdoc
save-analysis: handle missing field names
FIxes https://github.com/rust-lang-nursery/rls/issues/1031
rebasing and reviewer changes
Primarily refactoring `(Ident, Option<NodeId>)` to `Segment`
Fix tests and assertions; add some comments
more reviewer changes
|
|
|
|
|
|
|
|
Correct trailing ellipsis in name_from_pat
r? @GuillaumeGomez
|
|
Fix rustdoc and fulldeps tests
|
|
|
|
|
|
|
|
|
|
[rustdoc] Add lint for doc without codeblocks
Fixes #53805.
r? @QuietMisdreavus
|
|
r=QuietMisdreavus,GuillaumeGomez
[librustdoc] Disable spellcheck for search field
This disables spellchecking for the search field in the rustdoc web interface.
As someone who uses Safari to browse through Rust docs, spellchecking gets really annoying.
|
|
Detect if access to localStorage is forbidden by the user's browser
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: Use dyn keyword when rendering dynamic traits
The dyn keyword has been stable for a while now so rustdoc should start using it.
r? @QuietMisdreavus
|
|
|
|
pnkfelix:issue-54478-dont-prefer-dynamic-in-doc-tests, r=QuietMisdreavus
rustdoc: don't prefer dynamic linking in doc tests
This is an attempt to address the regression in #54478
This may be a case where the cure is worse than the disease, at least in the short term...
cc @alexcrichton
|
|
|
|
resolve: Scale back hard-coded extern prelude additions on 2015 edition
https://github.com/rust-lang/rust/pull/54404 stabilized `feature(extern_prelude)` on 2015 edition, including the hard-coded parts not passed with `--extern`.
First of all, I'd want to confirm that this is intended stabilization, rather than a part of the "extended beta" scheme that's going to be reverted before releasing stable.
(EDIT: to clarify - this is a question, I'm \*asking\* for confirmation, rather than give it.)
Second, on 2015 edition extern prelude is not so fundamentally tied to imports and is a mere convenience, so this PR scales them back to the uncontroversial subset.
The "uncontroversial subset" means that if libcore is injected it brings `core` into prelude, if libstd is injected it brings `std` and `core` into prelude.
On 2015 edition this can be implemented through the library prelude (rather than hard-coding in the compiler) right now, I'll do it in a follow-up PR.
UPDATE: The change is done for both 2015 and 2018 editions now as discussed below.
Closes https://github.com/rust-lang/rust/issues/53166
|
|
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
|
|
The dyn keyword has been stable for a while now so rustdoc should start using it.
|
|
r=Mark-Simulacrum
Check the invariant for `principal` inside the method
r? @Mark-Simulacrum
|
|
|
|
|
|
Fix mobile docs
Fixes #54836.
<img width="1440" alt="screen shot 2018-10-06 at 18 53 19" src="https://user-images.githubusercontent.com/3050060/46573683-1b4cd700-c999-11e8-9e6b-86a23b332e22.png">
r? @QuietMisdreavus
|
|
Improve error display for codeblocks in rustdoc
Part of #53919.
r? @QuietMisdreavus
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: overflow:auto doesn't work nicely on small screens
This property was introduced by 3f92ff34b5, but looks it doesn't
overwrap even without the property.
Fixes #54672.
|
|
Nest the `impl Trait` existential item inside the return type
fixes #54045
r? @cramertj
|
|
This property was introduced by 3f92ff34b5, but looks it doesn't
overwrap even without the property.
Fixes #54672.
|
|
|
|
|
|
|
|
This commit takes a different approach to add the `crate::` prefix to
item paths than previous commits. Previously, recursion was stopped
after a prelude crate name was pushed to the path. It is theorized that
this was the cause of the linking issues since the same path logic is
used for symbol names and that not recursing meant that details were
being missed that affect symbol names. As of this commit, instead of
ceasing recursion, a flag is passed through to any subsequent recursive
calls so that the same effect can be achieved by checking that flag.
|
|
In the 2018 edition, when suggesting traits to import that implement a
given method that is being invoked, suggestions will now include the
`crate::` prefix if the suggested trait is local to the current crate.
|
|
Bump to 1.31.0 and bootstrap from 1.30 beta
Closes #54594.
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #54564 (Add 1.29.1 release notes)
- #54567 (Include path in stamp hash for debuginfo tests)
- #54577 (rustdoc: give proc-macros their own pages)
- #54590 (std: Don't let `rust_panic` get inlined)
- #54598 (Remove useless lifetimes from `Pin` `impl`s.)
- #54604 (Added help message for `self_in_typedefs` feature gate)
- #54635 (Improve docs for std::io::Seek)
- #54645 (Compute Android gdb version in compiletest)
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
