Alex Crichton [Thu, 8 Jan 2015 17:22:03 +0000 (09:22 -0800)]
rollup merge of #20738: brson/feature-staging2
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.
Alex Crichton [Thu, 8 Jan 2015 17:21:57 +0000 (09:21 -0800)]
rollup merge of #19897: steveklabnik/trpl
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?
Steve Klabnik [Tue, 2 Dec 2014 14:20:48 +0000 (09:20 -0500)]
"The Rust Programming Language"
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.
Niko Matsakis [Thu, 8 Jan 2015 14:13:08 +0000 (09:13 -0500)]
Fix the actual bug for #20232: when creating the cmt for the implicit
deref that is associated with an overloaded index, we should not
consult the method lookup table. This deref is *always* a deref of an
`&T` and hence is never overloaded (and is also not present in the
tables; it has no "id" or other associated key).
Brian Anderson [Wed, 7 Jan 2015 23:48:16 +0000 (15:48 -0800)]
Improvements to feature staging
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.
Alex Crichton [Thu, 8 Jan 2015 01:17:34 +0000 (17:17 -0800)]
rollup merge of #20704: alexcrichton/hopefully-make-tests-less-spurious
These tests have all been failing spuroiusly on Windows from time to time, and
one suspicion is that the shilc thread outliving the main thread somehow causes
the problem. Switch all the tests over to using Thread::scoped instead of
Thread::spawn to see if it helps the issue.
Alex Crichton [Thu, 8 Jan 2015 01:17:32 +0000 (17:17 -0800)]
rollup merge of #20703: barosl/rustdoc-z-index-fallout
Due to the CSS changes done by the previous patch to make the line numbers clickable (#20092), the sidebar became unclickable. This PR reverts the changes and adopts an alternative approach.
Alex Crichton [Thu, 8 Jan 2015 01:17:31 +0000 (17:17 -0800)]
rollup merge of #20696: reem/unsized-typeid
This removes the needlessly constricting bound on `intrinsics::type_Id` and `TypeId::of`. Also fixes an ICE where using bounds on type parameters in extern blocks fails to resolve the used traits.
Alex Crichton [Thu, 8 Jan 2015 01:17:22 +0000 (17:17 -0800)]
rollup merge of #20663: brson/feature-staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system do a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Next steps are to disable the existing out-of-tree behavior for stability attributes, and convert the remaining system to be feature-based per the RFC. During the first beta cycle we will set these lints to 'forbid'.
Alex Crichton [Thu, 8 Jan 2015 01:17:19 +0000 (17:17 -0800)]
rollup merge of #20654: alexcrichton/stabilize-hash
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
Alex Crichton [Thu, 8 Jan 2015 01:17:15 +0000 (17:17 -0800)]
rollup merge of #20237: RustOS-Fork-Holding-Ground/master
libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.
Jonathan Reem [Tue, 6 Jan 2015 21:59:07 +0000 (22:59 +0100)]
Remove the unneeded Sized bound on TypeId creation
This bound is probably unintentional and is unnecessarily
constricting.
To facilitate this change, it was also necessary to modify
resolve to recurse on and resolve type parameters in extern { }
blocks. This fixes an ICE when using bounds on type parameters
during the declaration of intrinsics.
This also adds tests for TypeId on both Sized and Unsized
tests as well as a test for using type parameters and bounds
in extern { } blocks.
Added `box_syntax` feature gate; added to std and rustc crates for bootstrap.
To avoid using the feauture, change uses of `box <expr>` to
`Box::new(<expr>)` alternative, as noted by the feature gate message.
(Note that box patterns have no analogous trivial replacement, at
least not in general; you need to revise the code to do a partial
match, deref, and then the rest of the match.)
projects / rust.git / log