Currently we pass a `struct S(u64)` as an immediate value on i686, but a
`struct S { x: u64 }` is passed indirectly. This seems pretty wrong,
as they both have the same underlying LLVM type `{ i64 }`, no sense in
treating them differently.
Without this, rustbook was failing because it was expecting the
directory to exist. (Previously, rustbook was just silently failing to
install the CSS files due to this.)
There are hundreds of stackoverflow answers, reddit posts and blog
articles that link to these documents, so it's a nicer user experience
if they're not plain 404s.
The intention is to let these hang around only for relatively short
while. The alpha is likely to bring in many new users and they will be
reading the documents mentioned above.
Because we are warning about unstable APIs and there are many
of these yet, this creates a high likelyhood doc tests will
fail.
This doesn't seem right as a blanket policy to me anyway, though
certainly we want it in std. Probably more appropriate to add
a rustdoc option.
Because we are warning about unstable APIs and there are many
of these yet, this creates a high likelyhood doc tests will
fail.
This doesn't seem right as a blanket policy to me anyway, though
certainly we want it in std. Probably more appropriate to add
a rustdoc option.
This commit is an attempt to standardize the use of punctuation and
formatting in "The Rust Programming Language" as discussed in #19823.
- Convert bold text to italicized textcwhen referring to terminology.
- Convert single-quoted text to italicized or double-quoted text,
depending on context.
- Use double quotes only in the case of scare quotes or quotations.
On DragonFly pthread_{mutex,rwlock,condvar}_destroy() returns EINVAL
when called on a pthread_{mutex,rwlock,condvar}_t that was just
initialized via PTHREAD_{MUTEX,RWLOCK,CONDVAR}_INITIALIZER and not used
in the meantime or initialized via pthread_{mutex,rwlock,condvar}_init().
Change the code to treat a return value of EINVAL on DragonFly as success.
This gets rid of the 'experimental' level, removes the non-staged_api
case (i.e. stability levels for out-of-tree crates), and lets the
staged_api attributes use 'unstable' and 'deprecated' lints.
This makes the transition period to the full feature staging design
a bit nicer.
An updated version of https://github.com/rust-lang/rust/pull/19461
This version vendors aturon/rust-book@731f7bf and builds it when building the docs. This is almost great, except my `make`-foo is poor, so I have my own personal paths in `mk/docs.mk`. How should I best get around that?
/cc @brson
This pulls all of our long-form documentation into a single document,
nicknamed "the book" and formally titled "The Rust Programming
Language."
A few things motivated this change:
* People knew of The Guide, but not the individual Guides. This merges
them together, helping discoverability.
* You can get all of Rust's longform documentation in one place, which
is nice.
* We now have rustbook in-tree, which can generate this kind of
documentation. While its style is basic, the general idea is much
better: a table of contents on the left-hand side.
* Rather than a almost 10,000-line guide.md, there are now smaller files
per section.
