This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
RFC and audited implementations now have the `#[stable]` attribute
* Integers and floats no longer print a suffix
* Smart pointers no longer print details that they are a smart pointer
* Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
`Display` must be implemented. With the loss of `String`, this has moved into
libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
warned about due to warnings being emitted on stage1+
While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.
[breaking-change]
Closes#21436
This is wanted by external tooling that uses rustdoc. There are likely
some bugs when actually generating HTML output (which may expect to be
able to read the source) but all I need for now is the cleaned crate and
analysis.
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.
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.)
[breaking-change]
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 to 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.
Closes#16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
This commit takes a first pass at stabilizing `std::thread`:
* It removes the `detach` method in favor of two constructors -- `spawn`
for detached threads, `scoped` for "scoped" (i.e., must-join)
threads. This addresses some of the surprise/frustrating debug
sessions with the previous API, in which `spawn` produced a guard that
on destruction joined the thread (unless `detach` was called).
The reason to have the division in part is that `Send` will soon not
imply `'static`, which means that `scoped` thread creation can take a
closure over *shared stack data* of the parent thread. On the other
hand, this means that the parent must not pop the relevant stack
frames while the child thread is running. The `JoinGuard` is used to
prevent this from happening by joining on drop (if you have not
already explicitly `join`ed.) The APIs around `scoped` are
future-proofed for the `Send` changes by taking an additional lifetime
parameter. With the current definition of `Send`, this is forced to be
`'static`, but when `Send` changes these APIs will gain their full
flexibility immediately.
Threads that are `spawn`ed, on the other hand, are detached from the
start and do not yield an RAII guard.
The hope is that, by making `scoped` an explicit opt-in with a very
suggestive name, it will be drastically less likely to be caught by a
surprising deadlock due to an implicit join at the end of a scope.
* The module itself is marked stable.
* Existing methods other than `spawn` and `scoped` are marked stable.
The migration path is:
```rust
Thread::spawn(f).detached()
```
becomes
```rust
Thread::spawn(f)
```
while
```rust
let res = Thread::spawn(f);
res.join()
```
becomes
```rust
let res = Thread::scoped(f);
res.join()
```
[breaking-change]
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
This is a [breaking-change]. The new rules require that, for an impl of a trait defined
in some other crate, two conditions must hold:
1. Some type must be local.
2. Every type parameter must appear "under" some local type.
Here are some examples that are legal:
```rust
struct MyStruct<T> { ... }
// Here `T` appears "under' `MyStruct`.
impl<T> Clone for MyStruct<T> { }
// Here `T` appears "under' `MyStruct` as well. Note that it also appears
// elsewhere.
impl<T> Iterator<T> for MyStruct<T> { }
```
Here is an illegal example:
```rust
// Here `U` does not appear "under" `MyStruct` or any other local type.
// We call `U` "uncovered".
impl<T,U> Iterator<U> for MyStruct<T> { }
```
There are a couple of ways to rewrite this last example so that it is
legal:
1. In some cases, the uncovered type parameter (here, `U`) should be converted
into an associated type. This is however a non-local change that requires access
to the original trait. Also, associated types are not fully baked.
2. Add `U` as a type parameter of `MyStruct`:
```rust
struct MyStruct<T,U> { ... }
impl<T,U> Iterator<U> for MyStruct<T,U> { }
```
3. Create a newtype wrapper for `U`
```rust
impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { }
```
Because associated types are not fully baked, which in the case of the
`Hash` trait makes adhering to this rule impossible, you can
temporarily disable this rule in your crate by using
`#![feature(old_orphan_check)]`. Note that the `old_orphan_check`
feature will be removed before 1.0 is released.
This commit is an implementation of [RFC 526][rfc] which is a change to alter
the definition of the old `fmt::FormatWriter`. The new trait, renamed to
`Writer`, now only exposes one method `write_str` in order to guarantee that all
implementations of the formatting traits can only produce valid Unicode.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
One of the primary improvements of this patch is the performance of the
`.to_string()` method by avoiding an almost-always redundant UTF-8 check. This
is a breaking change due to the renaming of the trait as well as the loss of the
`write` method, but migration paths should be relatively easy:
* All usage of `write` should move to `write_str`. If truly binary data was
being written in an implementation of `Show`, then it will need to use a
different trait or an altogether different code path.
* All usage of `write!` should continue to work as-is with no modifications.
* All usage of `Show` where implementations just delegate to another should
continue to work as-is.
[breaking-change]
Closes#20352
This commit adds support for the compiler to distinguish between different forms
of lookup paths in the compiler itself. Issue #19767 has some background on this
topic, as well as some sample bugs which can occur if these lookup paths are not
separated.
This commits extends the existing command line flag `-L` with the same trailing
syntax as the `-l` flag. Each argument to `-L` can now have a trailing `:all`,
`:native`, `:crate`, or `:dependency`. This suffix indicates what form of lookup
path the compiler should add the argument to. The `dependency` lookup path is
used when looking up crate dependencies, the `crate` lookup path is used when
looking for immediate dependencies (`extern crate` statements), and the `native`
lookup path is used for probing for native libraries to insert into rlibs. Paths
with `all` are used for all of these purposes (the default).
The default compiler lookup path (the rustlib libdir) is by default added to all
of these paths. Additionally, the `RUST_PATH` lookup path is added to all of
these paths.
Closes#19767
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.
All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.
To migrate all crates, add the following to your `Cargo.toml`:
[dependencies]
rustc-serialize = "0.1.1"
And then add the following to your crate root:
extern crate "rustc-serialize" as rustc_serialize;
Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.
[breaking-change]
This commit shuffles around some CLI flags of the compiler to some more stable
locations with some renamings. The changes made were:
* The `-v` flag has been repurposes as the "verbose" flag. The version flag has
been renamed to `-V`.
* The `-h` screen has been split into two parts. Most top-level options (not
all) show with `-h`, and the remaining options (generally obscure) can be
shown with `--help -v` which is a "verbose help screen"
* The `-V` flag (version flag now) has lost its argument as it is now requested
with `rustc -vV` "verbose version".
* The `--emit` option has had its `ir` and `bc` variants renamed to `llvm-ir`
and `llvm-bc` to emphasize that they are LLVM's IR/bytecode.
* The `--emit` option has grown a new variant, `dep-info`, which subsumes the
`--dep-info` CLI argument. The `--dep-info` flag is now deprecated.
* The `--parse-only`, `--no-trans`, `--no-analysis`, and `--pretty` flags have
moved behind the `-Z` family of flags.
* The `--debuginfo` and `--opt-level` flags were moved behind the top-level `-C`
flag.
* The `--print-file-name` and `--print-crate-name` flags were moved behind one
global `--print` flag which now accepts one of `crate-name`, `file-names`, or
`sysroot`. This global `--print` flag is intended to serve as a mechanism for
learning various metadata about the compiler itself.
* The top-level `--pretty` flag was moved to a number of `-Z` options.
No warnings are currently enabled to allow tools like Cargo to have time to
migrate to the new flags before spraying warnings to all users.
cc https://github.com/rust-lang/rust/issues/19051
This commit shuffles around some CLI flags of the compiler to some more stable
locations with some renamings. The changes made were:
* The `-v` flag has been repurposes as the "verbose" flag. The version flag has
been renamed to `-V`.
* The `-h` screen has been split into two parts. Most top-level options (not
all) show with `-h`, and the remaining options (generally obscure) can be
shown with `--help -v` which is a "verbose help screen"
* The `-V` flag (version flag now) has lost its argument as it is now requested
with `rustc -vV` "verbose version".
* The `--emit` option has had its `ir` and `bc` variants renamed to `llvm-ir`
and `llvm-bc` to emphasize that they are LLVM's IR/bytecode.
* The `--emit` option has grown a new variant, `dep-info`, which subsumes the
`--dep-info` CLI argument. The `--dep-info` flag is now deprecated.
* The `--parse-only`, `--no-trans`, and `--no-analysis` flags have
moved behind the `-Z` family of flags.
* The `--debuginfo` and `--opt-level` flags were moved behind the top-level `-C`
flag.
* The `--print-file-name` and `--print-crate-name` flags were moved behind one
global `--print` flag which now accepts one of `crate-name`, `file-names`, or
`sysroot`. This global `--print` flag is intended to serve as a mechanism for
learning various metadata about the compiler itself.
No warnings are currently enabled to allow tools like Cargo to have time to
migrate to the new flags before spraying warnings to all users.
This commit is part of a series that introduces a `std::thread` API to
replace `std::task`.
In the new API, `spawn` returns a `JoinGuard`, which by default will
join the spawned thread when dropped. It can also be used to join
explicitly at any time, returning the thread's result. Alternatively,
the spawned thread can be explicitly detached (so no join takes place).
As part of this change, Rust processes now terminate when the main
thread exits, even if other detached threads are still running, moving
Rust closer to standard threading models. This new behavior may break code
that was relying on the previously implicit join-all.
In addition to the above, the new thread API also offers some built-in
support for building blocking abstractions in user space; see the module
doc for details.
Closes#18000
[breaking-change]
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
This commit removes the `std::local_data` module in favor of a new
`std::thread_local` module providing thread local storage. The module provides
two variants of TLS: one which owns its contents and one which is based on
scoped references. Each implementation has pros and cons listed in the
documentation.
Both flavors have accessors through a function called `with` which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of [RFC 461][rfc] and full details can be found in
that RFC.
This is a breaking change due to the removal of the `std::local_data` module.
All users can migrate to the new thread local system like so:
thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None)))
The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as
an implementation detail which must now be explicitly stated by users.
[rfc]: https://github.com/rust-lang/rfcs/pull/461
[breaking-change]
The struct_variant is not gated anymore. This commit just removes it and the resulting warnings when compiling rust. Now compiles with the snapshot from 11/18 (as opposed to PR #19014)
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:
* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
Signed, and Float. It is recommended to instead use Show wherever possible or
to use adaptor structs to implement other methods of formatting.
* The format specifier for Boolean has changed from `t` to `b`.
* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
struct instead of an enum. The `WriteError` variant no longer exists.
* The `format_args_method!` macro has been removed with no replacement. Alter
code to use the `format_args!` macro instead.
* The public fields of a `Formatter` have become read-only with no replacement.
Use a new formatting string to alter the formatting flags in combination with
the `write!` macro. The fields can be accessed through accessor methods on the
`Formatter` structure.
Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]
Closes#18904
Reduces memory usage significantly and opens opportunities for more parallel compilation.
This PR was previously #19002 but I closed it because bors didn't seem to recognize the `r+` annotations there.
The trait has an obvious, sensible implementation directly on vectors so
the MemWriter wrapper is unnecessary. This will halt the trend towards
providing all of the vector methods on MemWriter along with eliminating
the noise caused by conversions between the two types. It also provides
the useful default Writer methods on Vec<u8>.
After the type is removed and code has been migrated, it would make
sense to add a new implementation of MemWriter with seeking support. The
simple use cases can be covered with vectors alone, and ones with the
need for seeks can use a new MemWriter implementation.
This commit deprecates the entire libtime library in favor of the
externally-provided libtime in the rust-lang organization. Users of the
`libtime` crate as-is today should add this to their Cargo manifests:
[dependencies.time]
git = "https://github.com/rust-lang/time"
To implement this transition, a new function `Duration::span` was added to the
`std::time::Duration` time. This function takes a closure and then returns the
duration of time it took that closure to execute. This interface will likely
improve with `FnOnce` unboxed closures as moving in and out will be a little
easier.
Due to the deprecation of the in-tree crate, this is a:
[breaking-change]
cc #18855, some of the conversions in the `src/test/bench` area may have been a
little nicer with that implemented
Previously, the stability summary page attempted to associate impl
blocks with the module in which they were defined, rather than the
module defining the type they apply to (which is usually, but not
always, the same). Unfortunately, due to the basic architecture of
rustdoc, this meant that impls from re-exports were not being counted.
This commit makes the stability summary work the same way that rustdoc's
rendered output does: all methods are counted alongside the type they
apply to, no matter where the methods are defined.
In addition, for trait impl blocks only the stability of the overall
block is counted; the stability of the methods within is not
counted (since that stability level is part of the trait definition).
Fixes#18812
* Moves multi-collection files into their own directory, and splits them into seperate files
* Changes exports so that each collection has its own module
* Adds underscores to public modules and filenames to match standard naming conventions
(that is, treemap::{TreeMap, TreeSet} => tree_map::TreeMap, tree_set::TreeSet)
* Renames PriorityQueue to BinaryHeap
* Renames SmallIntMap to VecMap
* Miscellanious fallout fixes
[breaking-change]
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
Now that rustdoc is spawning a child task, the program won't exit with a default
error code if the main task fails (because it never fails). This commit forces
the main task to wait for a child task in order to correctly propagate failure.
Closes#16341
There's a good long comment explaining why. The tl;dr; is that I have no idea
why this is necessary, but it gets --test to work on windows which is something,
right?
cc #13259
cc #16275
cc rust-lang/cargo#302
This ensures that the name of the crate is set from the command line for tests
so the auto-injection of `extern crate <name>` in doc tests works correctly.
rustdoc currently determines whether to produce a table of
contents (along with numbered sections) from the input type: yes for
markdown input, no for Rust input. This commit adds a flag to disable
the table of contents for markdown input, which is useful for embedding
the output in a larger context.
This commit adds a crate-level dashboard summarizing the stability
levels of all items for all submodules of the crate.
The information is also written as a json file, intended for consumption
by pages like http://huonw.github.io/isrustfastyet/Closes#13541
This commit removes all support in the compiler for the #[crate_id] attribute
and all of its derivative infrastructure. A list of the functionality removed is:
* The #[crate_id] attribute no longer exists
* There is no longer the concept of a version of a crate
* Version numbers are no longer appended to symbol names
* The --crate-id command line option has been removed
To migrate forward, rename #[crate_id] to #[crate_name] and only the name of the
crate itself should be mentioned. The version/path of the old crate id should be
removed.
For a transitionary state, the #[crate_id] attribute is still accepted if
the #[crate_name] is not present, but it is warned about if it is the only
identifier present.
RFC: 0035-remove-crate-id
[breaking-change]
This obsoletes the old `to_err_msg` method. Replace
println!("Error: {}", failure.to_err_msg())
let string = failure.to_err_msg();
with
println!("Error: {}", failure)
let string = failure.to_str();
[breaking-change]
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
[breaking-change]
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
[breaking-change]
This grows a new option inside of rustdoc to add the ability to submit examples
to an external website. If the `--markdown-playground-url` command line option
or crate doc attribute `html_playground_url` is present, then examples will have
a button on hover to submit the code to the playground specified.
This commit enables submission of example code to play.rust-lang.org. The code
submitted is that which is tested by rustdoc, not necessarily the exact code
shown in the example.
Closes#14654
This commit moves reflection (as well as the {:?} format modifier) to a new
libdebug crate, all of which is marked experimental.
This is a breaking change because it now requires the debug crate to be
explicitly linked if the :? format qualifier is used. This means that any code
using this feature will have to add `extern crate debug;` to the top of the
crate. Any code relying on reflection will also need to do this.
Closes#12019
[breaking-change]
See #13983 and #14000.
Fix was originally authored by alexcrichton and then rebased a couple
times by pnkfelix, most recently atop PR 13954.
----
Regarding the change to librustdoc/lib.rs, to do `map_err` before
unwrapping a `TqskResult`: I do not understand how master is passing
without this change or something like it, since `Box<Any:Send>` does
not implement `Show`. (Is this something that is only a problem for
the snapshot stage0 compiler?) Still, the change I have put in here
(which was added as part of a rebase after alex's review) seems
harmless to me to apply to rustdoc at all stages, since a call to
`unwrap` is just going to `fail!` on the err case anyway.
The goal of this refactoring is to make the rustc driver code easier to understand and use. Since this is as close to an API as we have, I think it is important that it is nice. On getting stuck in, I found that there wasn't as much to change as I'd hoped to make the stage... fns easier to use by tools.
This patch only moves code around - mostly just moving code to different files, but a few extracted method refactorings too. To summarise the changes: I added driver::config which handles everything about configuring the compiler. driver::session now just defines and builds session objects. I moved driver code from librustc/lib.rs to librustc/driver/mod.rs so all the code is one place. I extracted methods to make emulating the compiler without being the compiler a little easier. Within the driver directory, I moved code around to more logically fit in the modules.
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]
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]
`Reader`, `Writer`, `MemReader`, `MemWriter`, and `MultiWriter` now work with `Vec<u8>` instead of `~[u8]`. This does introduce some extra copies since `from_utf8_owned` isn't usable anymore, but I think that can't be helped until `~str`'s representation changes.
These syntax extensions need a place to be documented, and this starts passing a
`--cfg dox` parameter to `rustdoc` when building and testing documentation in
order to document macros so that they have no effect on the compiled crate, but
only documentation.
Closes#5605
These syntax extensions need a place to be documented, and this starts passing a
`--cfg dox` parameter to `rustdoc` when building and testing documentation in
order to document macros so that they have no effect on the compiled crate, but
only documentation.
Closes#5605
A major discoverability issue with rustdoc is that all crates have their
documentation built in isolation, so it's difficult when looking at the
documentation for libstd to learn that there's a libcollections crate with a
HashMap in it.
This commit moves rustdoc a little closer to improving the multiple crate
experience. This unifies all search indexes for all crates into one file so all
pages share the same search index. This allows searching to work across crates
in the same documentation directory (as the standard distribution is currently
built).
This strategy involves updating a shared file amongst many rustdoc processes, so
I implemented a simple file locking API for handling synchronization for updates
to the shared files.
cc #12554
Brian Anderson
Alex Crichton
Tom Jakubowski
Nick Cameron
Huon Wilson
Felix S. Klock II
Aaron Turon
Sean McArthur
Dylan Ede
Keegan McAllister
Ben Foppa
Jorge Aparicio
Niko Matsakis
Florian Hahn
Corey Farwell
bors
Alexis Beingessner
Patrick Walton
Corey Richardson
Alexander Light
Steven Fackler
Simon Wollwage
Daniel Micay
Steve Klabnik
Luqman Aden
Eduard Burtescu
inrustwetrust
wickerwaka
Mike Robinson
Adolfo Ochagavía
Richo Healey
zzmp
Piotr Jawniak
Robert Buonpastore
Kevin Ballard
Jonathan S
Kang Seonghoon
Flavio Percoco