This commit brings the local_data api up to modern rust standards with a few key
improvements:
* All functionality is now exposed as a method on the keys themselves. Instead
of importing std::local_data, you now use "key.set()" and "key.get()".
* All closures have been removed in favor of RAII functionality. This means that
get() and get_mut() no long require closures, but rather return
Option<SmartPointer> where the smart pointer takes care of relinquishing the
borrow and also implements the necessary Deref traits
* The modify() function was removed to cut the local_data interface down to its
bare essentials (similarly to how RefCell removed set/get).
[breaking-change]
This commit brings the local_data api up to modern rust standards with a few key
improvements:
* The `pop` and `set` methods have been combined into one method, `replace`
* The `get_mut` method has been removed. All interior mutability should be done
through `RefCell`.
* All functionality is now exposed as a method on the keys themselves. Instead
of importing std::local_data, you now use "key.replace()" and "key.get()".
* All closures have been removed in favor of RAII functionality. This means that
get() and get_mut() no long require closures, but rather return
Option<SmartPointer> where the smart pointer takes care of relinquishing the
borrow and also implements the necessary Deref traits
* The modify() function was removed to cut the local_data interface down to its
bare essentials (similarly to how RefCell removed set/get).
[breaking-change]
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes#10025
[breaking-change]
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
r? @brson or @alexcrichton or whoever
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
How to update your code:
* Instead of `~EXPR`, you should write `box EXPR`.
* Instead of `~TYPE`, you should write `Box<Type>`.
* Instead of `~PATTERN`, you should write `box PATTERN`.
[breaking-change]
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes#10025
[breaking-change]
This commit removes the inherited documentation from type pages. This generally
just clutters up the page when you can click through to the trait itself to get
all the meaty documentation.
Closes#11991
This primary fix brought on by this upgrade is the proper matching of the ```
and ~~~ doc blocks. This also moves hoedown to a git submodule rather than a
bundled repository.
Additionally, hoedown is stricter about code blocks, so this ended up fixing a
lot of invalid code blocks (ending with " ```" instead of "```", or ending with
"~~~~" instead of "~~~").
Closes#12776
This allows writing code examples which pass all analysis of the compiler, but
don't actually link. A good example is examples that use extern {} blocks.
Closes#12903
Rustdoc currently doesn't inline documentation of a `pub use` if the target is
publicly reachable. This changes rustdoc to allow a #[doc(inline)] attribute to
force inlining the documentation, regardless of whether the targe is public or
not.
Closes#13045
These fonts were moved into place by rust's makefiles, but rustdoc is widely
used outside of rustc itself. This moves the fonts into the rustdoc binary,
similarly to the other static assets, and writes them to the output location
whenever rustdoc generates documentation.
Closes#13593Closes#13787
Clearly storing them as `char` is semantically nicer, but this also
fixes a bug whereby `quote_expr!(cx, 'a')` wasn't working, because the
code created by quotation was not matching the actual AST definitions.
In the process, `Splits` got changed to be more like `CharSplits` in `str` to present the DEI interface.
Note that `treemap` still has a `rev_iter` function because it seems like it would be a significant interface change to expose a DEI - the iterator would have to gain an extra pointer, the completion checks would be more complicated, and it isn't easy to check that such an implementation is correct due to the use of unsafety to subvert the aliasing properties of `&mut`.
This fixes#9391.
All links inside docblocks will have their color set to `#4e8bca` (a
light blue color to contrast against the black text). This color also
offers a visible contrast from the surrounding text if viewed as
grayscale, making it suitable for accessability.
Docblock links will also be underlined when hovered over.
Currently, in both chrome and firefox, if I type something in the search box in the reference docs I get immediately the search results. That's great. However, if I want to go back to the doc I was reading and try to press the back button, I am immediately forwarded again to the search results. This is caused by the fact that the search term is (deliberately) left in the search box, and the search() function is called as if I typed the search term again.
I disabled calling the search() function if there's no search term in the URL, and now it seems to work fine.
I hope I'm sending the pull request correctly - I'm not really used to git and github.
This commit deprecates rev_iter, mut_rev_iter, move_rev_iter everywhere (except treemap) and also
deprecates related functions like rsplit, rev_components, and rev_str_components. In every case,
these functions can be replaced with the non-reversed form followed by a call to .rev(). To make this
more concrete, a translation table for all functional changes necessary follows:
* container.rev_iter() -> container.iter().rev()
* container.mut_rev_iter() -> container.mut_iter().rev()
* container.move_rev_iter() -> container.move_iter().rev()
* sliceorstr.rsplit(sep) -> sliceorstr.split(sep).rev()
* path.rev_components() -> path.components().rev()
* path.rev_str_components() -> path.str_components().rev()
In terms of the type system, this change also deprecates any specialized reversed iterator types (except
in treemap), opting instead to use Rev directly if any type annotations are needed. However, since
methods directly returning reversed iterators are now discouraged, the need for such annotations should
be small. However, in those cases, the general pattern for conversion is to take whatever follows Rev in
the original reversed name and surround it with Rev<>:
* RevComponents<'a> -> Rev<Components<'a>>
* RevStrComponents<'a> -> Rev<StrComponents<'a>>
* RevItems<'a, T> -> Rev<Items<'a, T>>
* etc.
The reasoning behind this change is that it makes the standard API much simpler without reducing readability,
performance, or power. The presence of functions such as rev_iter adds more boilerplate code to libraries
(all of which simply call .iter().rev()), clutters up the documentation, and only helps code by saving two
characters. Additionally, the numerous type synonyms that were used to make the type signatures look nice
like RevItems add even more boilerplate and clutter up the docs even more. With this change, all that cruft
goes away.
[breaking-change]
This PR is primarily motivated by (and fixes) #12926.
We currently only have a span for the individual item itself and not for the referred contents. This normally does not cause a problem since both are located in the same file; it *is* possible that the contained statement or item is located in the other file (the syntax extension can do that), but even in that case the syntax extension should be located in the same file as the item. The module item (i.e. `mod foo;`) is the only exception here, and thus warrants a special treatment.
Rustdoc would now distinguish `mod foo;` from `mod foo {...}` by checking if the span for the module item and module contents is in different files. If it's the case, we'd prefer module contents over module item. There are alternative strategies, but as noted above we will have some corner cases if we don't record the contents span explicitly.
the basic strategy is to distinguish `mod foo;` from `mod foo {...}`
by checking if the span for the module item and module contents is
in different files. if it's the case, we prefer module contents.
it is technically possible to fix#12926 without changing the AST,
probably by checking the individual items' span. this is not without
a problem though, since it is possible that some items inside
`mod foo {...}` may have originated from other file (e.g. `include!`).
therefore it is better to record both spans explicitly.
It reflected the obsolete syntax `use a, b, c;` and did not make past the parser (though it was a non-fatal error so we can continue). This legacy affected many portions of rustc and rustdoc as well, so this PR cleans them up altogether.
As a side effect of cleanup, we now have `SCHEMA_VERSION` in `rustdoc::clean` (instead of the crate root), so it has a better chance to be updated when `rustdoc::clean` gets updated.
it reflected the obsolete syntax `use a, b, c;` and did not make
past the parser (though it was a non-fatal error so we can continue).
this legacy affected many portions of rustc and rustdoc as well,
so this commit cleans them up altogether.
Now with proper checking of enums and allows unsized fields as the last field in a struct or variant. This PR only checks passing of unsized types and distinguishing them from sized ones. To be safe we also need to control storage.
Closes issues #12969 and #13121, supersedes #13375 (all the discussion there is valid here too).
This currently requires linking against a library like libquadmath (or
libgcc), because compiler-rt barely has any support for this and most
hardware does not yet have 128-bit precision floating point. For this
reason, it's currently hidden behind a feature gate.
When compiler-rt is updated to trunk, some tests can be added for
constant evaluation since there will be support for the comparison
operators.
Closes#13381
The fields of tuple structs recently gained the ability to have privacy
associated with them, but rustdoc was not updated accodingly. This moves the
struct field filtering to the rendering phase in order to preserve the ordering
of struct fields to allow tuple structs to have their private fields printed as
underscores.
Closes#13594
