This commit alters rustdoc to crawl the metadata of upstream libraries in order
to fill in default methods for traits implemented in downstream crates. This,
for example, documents the `insert` function on hash maps.
This is a fairly lossy extraction from the metadata. Documentation and
attributes are lost, but they aren't used anyway. Unfortunately, argument names
are also lost because they are not present in the metadata. Source links are
also lost because the spans are not serialized.
While not perfect, it appears that presenting this documentation through rustdoc
is much better than nothing, so I wanted to land this to allow iteration on it
later on.
1. Wherever the `buf` field of a `Formatter` was used, the `Formatter` is used
instead.
2. The usage of `write_fmt` is minimized as much as possible, the `write!` macro
is preferred wherever possible.
3. Usage of `fmt::write` is minimized, favoring the `write!` macro instead.
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]
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
This removes the `priv` keyword from the language and removes private enum
variants as a result. The remaining use cases of private enum variants were all
updated to be a struct with one private field that is a private enum.
RFC: 0006-remove-priv
Closes#13535
Closures did not have their bounds printed at all, nor their lifetimes. Trait
bounds were also printed in angle brackets rather than after a colon with a '+'
inbetween them.
Note that on the current task::spawn [1] documentation page, there is no mention
of a `Send` bound even though it is crucially important!
[1] - http://static.rust-lang.org/doc/master/std/task/fn.task.html
libstd: Implement `StrBuf`, a new string buffer type like `Vec`, and port all code over to use it.
Rebased & tests-fixed version of https://github.com/mozilla/rust/pull/13269
This commit deals with the fallout of the previous change by making tuples
structs have public fields where necessary (now that the fields are private by
default).
The `~str` type is not long for this world as it will be superseded by the
soon-to-come DST changes for the language. The new type will be
`~Str`, and matching over the allocation will no longer be supported.
Matching on `&str` will continue to work, in both a pre and post DST world.
This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.
The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.
The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.
Close#12037
The first setp for #9880 is to add a new `crate` keyword. This PR does exactly that. I took a chance to refactor `parse_item_foreign_mod` and I broke it down into 2 separate methods to isolate each feature.
The next step will be to push a new stage0 snapshot and then get rid of all `extern mod` around the code.
This patch replaces all `crate` usage with `krate` before introducing the
new keyword. This ensures that after introducing the keyword, there
won't be any compilation errors.
krate might not be the most expressive substitution for crate but it's a
very close abbreviation for it. `module` was already used in several
places already.
This was just incorrectly handled before, the path component shouldn't be looked
at at all (we used absolute paths everywhere instead of relative to the current
module location).
Closes#9861
The general idea of hyperlinking between crates is that it should require as
little configuration as possible, if any at all. In this vein, there are two
separate ways to generate hyperlinks between crates:
1. When you're generating documentation for a crate 'foo' into folder 'doc',
then if foo's external crate dependencies already have documented in the
folder 'doc', then hyperlinks will be generated. This will work because all
documentation is in the same folder, allowing links to work seamlessly both
on the web and on the local filesystem browser.
The rationale for this use case is a package with multiple libraries/crates
that all want to link to one another, and you don't want to have to deal with
going to the web. In theory this could be extended to have a RUST_PATH-style
searching situtation, but I'm not sure that it would work seamlessly on the
web as it does on the local filesystem, so I'm not attempting to explore this
case in this pull request. I believe to fully realize this potential rustdoc
would have to be acting as a server instead of a static site generator.
2. One of foo's external dependencies has a #[doc(html_root_url = "...")]
attribute. This means that all hyperlinks to the dependency will be rooted at
this url.
This use case encompasses all packages using libstd/libextra. These two
crates now have this attribute encoded (currently at the /doc/master url) and
will be read by anything which has a dependency on libstd/libextra. This
should also work for arbitrary crates in the wild that have online
documentation. I don't like how the version is hard-wired into the url, but I
think that this may be a case-by-case thing which doesn't end up being too
bad in the long run.
Closes#9539
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes#6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
