messages when the pattern is refutable.
This means the compiler points directly to the pattern and said that the
problem is the pattern being refutable (rather than just saying that
some value isn't covered in the `match` as it did previously).
Fixes#14390.
The current tutorial says that the only way to get master is to build from source, which isn't true anymore - nightly binaries and an installer for Mac OS X are now available at the install page: http://www.rust-lang.org/install.html . Feedback very much welcome! Addresses issue #13578.
This patch changes the internals of `Regex` and `regex!()` such that
```rust
static RE: Regex = regex!(...);
```
is valid. It doesn't change anything about the actual regex implementation, it just changes the type to something that can be constructed as a const expression.
With the test runner using ::std::os::args(), and std::std::os now being
a re-export of realstd::os, there's no more need for realstd stuff
mucking up rt::args.
Remove the one test of os::args(), as it's not very useful and it won't
work anymore now that rt::args doesn't use realstd.
As part of the libstd facade (cc #13851), rustdoc is taught to inline documentation across crate boundaries through the usage of a `pub use` statement. This is done to allow libstd to maintain the facade that it is a standalone library with a defined public interface (allowing us to shuffle around what's underneath it).
A preview is available at http://people.mozilla.org/~acrichton/doc/std/index.html
These links work by hyperlinking back to the actual documentation page with a
query parameter which will be recognized and then auto-click the appropriate
[src] link.
Within the documentation for a crate, all hyperlinks to reexported items don't
go across crates, but rather to the items in the crate itself. This will allow
references to Option in the standard library to link to the standard library's
Option, instead of libcore's.
This does mean that other crate's links for Option will still link to libcore's
Option.
This commit teaches rustdoc to inline the documentation for the destination of a
`pub use` statement across crate boundaries. This is intended for the standard
library's facade to show the fact that the facade is just an implementation
detail rather than the api of the standard library itself.
This starts out by inlining traits and functions, but more items will come soon.
The current drawback of this system is that hyperlinks across crates sill go to
the original item's definition rather than the reexported location.
Converts `StrBuf` to `String` throughout rustc and the standard library.
Tests all pass locally, but usual caveats about platforms that aren't OSX apply since I don't have a test environment handy.
@alexcritchon mentioned that @pcwalton may have a patch incoming that should block this?
closes#14312
Paper over privacy issues with Deref by changing field names.
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
cc #12808
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
cc #12808
The compiler now tracks which attributes were actually looked at during the compilation process and warns for those that were unused.
Some things of note:
* The tracking is done via thread locals, as it made the implementation more straightforward. Note that this shouldn't hamper any future parallelization as each task can have its own thread local state which can be merged for the lint pass. If there are serious objections to this, I can restructure things to explicitly pass the state around.
* There are a number of attributes that have to be special-cased and globally whitelisted. This happens for four reasons:
* The `doc` and `automatically_derived` attributes are used by rustdoc, but not by the compiler.
* The crate-level attributes `license`, `desc` and `comment` aren't currently used by anything.
* Stability attributes as well as `must_use` are checked only when the tagged item is used, so we can't guarantee that the compiler's looked at them.
* 12 attributes are used only in trans, which happens after the lint pass.
#14300 is adding infrastructure to track lint state through trans, which this lint should also be able to use to handle the last case. For the other attributes, the right solution would probably involve a specific pass to mark uses that occur in the correct context. For example, a `doc` attribute attached to a match arm should generate a warning, but will not currently.
RFC: 0002-attribute-usage
