bors [Sat, 2 May 2015 09:55:13 +0000 (09:55 +0000)]
Auto merge of #25027 - Manishearth:deriving_attr, r=huonw
Adds an `attrs` field to `FieldInfo` which lets one check the attributes on
a field whilst expanding.
This lets deriving plugins be more robust, for example providing the ability to
"ignore" a field for the purpose of deriving, or perhaps handle the field a
different way.
bors [Sat, 2 May 2015 02:48:53 +0000 (02:48 +0000)]
Auto merge of #25015 - alexcrichton:rwlock-check-ret, r=aturon
Apparently implementations are allowed to return EDEADLK instead of blocking
forever, in which case this can lead to unsafety in the `RwLock` primitive
exposed by the standard library. A debug-build of the standard library would
have caught this error (due to the debug assert), but we don't ship debug
builds right now.
This commit adds explicit checks for the EDEADLK error code and triggers a panic
to ensure the call does not succeed.
bors [Sat, 2 May 2015 01:03:43 +0000 (01:03 +0000)]
Auto merge of #24792 - alexcrichton:issue-24748, r=alexcrichton
Ensures that the same error type is propagated throughout. Unnecessary leakage
of the internals is prevented through the usage of stability attributes.
Alex Crichton [Fri, 24 Apr 2015 22:58:27 +0000 (15:58 -0700)]
std: Don't use a wrapper for the float error type
Ensures that the same error type is propagated throughout. Unnecessary leakage
of the internals is prevented through the usage of stability attributes.
bors [Fri, 1 May 2015 22:54:09 +0000 (22:54 +0000)]
Auto merge of #25006 - alexcrichton:unstable-indexing, r=aturon
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Alex Crichton [Thu, 30 Apr 2015 22:24:39 +0000 (15:24 -0700)]
std: Remove index notation on slice iterators
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Rollup merge of #24981 - carols10cents:remove-more-priv, r=alexcrichton
Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (#13547, #8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)).
One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! :fallen_leaf: :ocean:
bors [Fri, 1 May 2015 08:33:08 +0000 (08:33 +0000)]
Auto merge of #24965 - arielb1:instant-reject, r=nikomatsakis
This uses a (per-trait) hash-table to separate impls from different TraitDefs, and makes coherence go so much quicker. I will post performance numbers tomorrow.
This is still WIP, as when there's an overlap error, impls can get printed in the wrong order, which causes a few issues. Should I pick the local impl with the smallest NodeId to print?
bors [Fri, 1 May 2015 04:22:53 +0000 (04:22 +0000)]
Auto merge of #24793 - aturon:io-error-any, r=alexcrichton
This commit brings the `Error` trait in line with the [Error interoperation
RFC](https://github.com/rust-lang/rfcs/pull/201) by adding downcasting,
which has long been intended. This change means that for any `Error`
trait objects that are `'static`, you can downcast to concrete error
types.
To make this work, it is necessary for `Error` to inherit from
`Reflect` (which is currently used to mark concrete types as "permitted
for reflection, aka downcasting"). This is a breaking change: it means
that impls like
```rust
impl<T> Error for MyErrorType<T> { ... }
```
must change to
```rust
impl<T: Reflect> Error for MyErrorType<T> { ... }
```
This commit furthermore marks `Reflect` as stable, since we are already
essentially committed to it via `Any`. Note that in the future, if we
determine that the parametricity aspects of `Reflect` are not needed, we
can deprecate the trait and provide a blanket implementation for it
for *all* types (rather than by using OIBIT), which would allow all
mentions of `Reflect` to be dropped over time. So there is not a strong
commitment here.
This commit brings the `Error` trait in line with the [Error interoperation
RFC](https://github.com/rust-lang/rfcs/pull/201) by adding downcasting,
which has long been intended. This change means that for any `Error`
trait objects that are `'static`, you can downcast to concrete error
types.
To make this work, it is necessary for `Error` to inherit from
`Reflect` (which is currently used to mark concrete types as "permitted
for reflection, aka downcasting"). This is a breaking change: it means
that impls like
```rust
impl<T> Error for MyErrorType<T> { ... }
```
must change to something like
```rust
impl<T: Reflect> Error for MyErrorType<T> { ... }
```
except that `Reflect` is currently unstable (and should remain so for
the time being). For now, code can instead bound by `Any`:
```rust
impl<T: Any> Error for MyErrorType<T> { ... }
```
which *is* stable and has `Reflect` as a super trait. The downside is
that this imposes a `'static` constraint, but that only
constrains *when* `Error` is implemented -- it does not actually
constrain the types that can implement `Error`.
Alex Crichton [Thu, 30 Apr 2015 23:37:41 +0000 (16:37 -0700)]
std: Always check for EDEADLK in rwlocks on unix
Apparently implementations are allowed to return EDEADLK instead of blocking
forever, in which case this can lead to unsafety in the `RwLock` primitive
exposed by the standard library. A debug-build of the standard library would
have caught this error (due to the debug assert), but we don't ship debug
builds right now.
This commit adds explicit checks for the EDEADLK error code and triggers a panic
to ensure the call does not succeed.
Auto merge of #24924 - carols10cents:grammar-improvements, r=pnkfelix
I'm interested in helping out with #16676 but more in the grammar than the reference-- here's my first chunk, more to come!! :tada:
I did pull a bit *out* of the reference, though, that was more relevant to the grammar but wasn't moved over as part of #24729.
I'm looking at, e.g. https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs, as the source of truth, please let me know if I should be checking against something else instead/in addition.
The former stopped making sense when we started interning substs and made
TraitRef a 2-word copy type, and I'm moving the latter into an arena as
they live as long as the type context.
Auto merge of #24884 - michaelsproul:extended-errors, r=nrc
I've been working on improving the diagnostic registration system so that it can:
* Check uniqueness of error codes *across the whole compiler*. The current method using `errorck.py` is prone to failure as it relies on simple text search - I found that it breaks when referencing an error's ident within a string (e.g. `"See also E0303"`).
* Provide JSON output of error metadata, to eventually facilitate HTML output, as well as tracking of which errors need descriptions. The current schema is:
```
<error code>: {
"description": <long description>,
"use_site": {
"filename": <filename where error is used>,
"line": <line in file where error is used>
}
}
```
[Here's][metadata-dump] a pretty-printed sample dump for `librustc`.
One thing to note is that I had to move the diagnostics arrays out of the diagnostics modules. I really wanted to be able to capture error usage information, which only becomes available as a crate is compiled. Hence all invocations of `__build_diagnostics_array!` have been moved to the ends of their respective `lib.rs` files. I tried to avoid moving the array by making a plugin that expands to nothing but couldn't invoke it in item position and gave up on hackily generating a fake item. I also briefly considered using a lint, but it seemed like it would impossible to get access to the data stored in the thread-local storage.
The next step will be to generate a web page that lists each error with its rendered description and use site. Simple mapping and filtering of the metadata files also allows us to work out which error numbers are absent, which errors are unused and which need descriptions.
Alex Crichton [Wed, 29 Apr 2015 22:45:57 +0000 (15:45 -0700)]
rollup merge of #24961: nham/net_docs_cleanup
Changes made include adding missing punctuation, adding missing words, and converting uses of "Gets" to "Returns" in libstd/net/addr.rs to make it more consistent with the other documentation.
Alex Crichton [Wed, 29 Apr 2015 22:45:56 +0000 (15:45 -0700)]
rollup merge of #24953: tamird/android-pie
This is OK to do given:
- PIE is supported on Android starting with API 16.
- The bots are running API 18.
- API < 16 now has a 12.5% market share[0] as of 2015-04-29.
Alex Crichton [Wed, 29 Apr 2015 22:45:55 +0000 (15:45 -0700)]
rollup merge of #24952: pnkfelix/put-back-missing-dash-g-in-24687-test
Add `-g` (to testcase) that I should have included in PR #24932.
Note it is safe, with respect to autobuilds, to land before #24945.
(In other words, landing this sooner won't break things for anyone any
worse than they were already broken, since there are *other* tests
that also add `-g` to their flags via `compile-flags: -g`.)
Alex Crichton [Wed, 29 Apr 2015 22:45:54 +0000 (15:45 -0700)]
rollup merge of #24945: pnkfelix/fixes-for-dash-g-handling
Fixes for -g handling
First:
* decouples our handling of `-g` for the test suite from our handling of `-g` for the rest of the compiler/stdlib building.
* Namely, if you do `--enable-debug` or `--enable-debuginfo`, that should only affect `rustc` and the standard library crates; the tests should all continue to compile without `-g` unless:
* you pass `--enable-debuginfo-tests`, or
* the test itself requests the `-g` option (e.g. via a `// compile-flags: -g` embedded comment).
Second:
* Makes `rustc` more flexible in that it now accepts multiple occurrences of `-g -g`
* (as a drive-by, I gave `-O` the same treatment: multiple occurrences of `-O` are treated as synonymous as a single occurrence of `-O`.
Alex Crichton [Wed, 29 Apr 2015 22:45:51 +0000 (15:45 -0700)]
rollup merge of #24931: jooert/patch-1
Since #24783, the style guidelines recommend that unit tests should live in a submodule `tests` rather than `test` to not clash with the possible use of libtest. This is especially important for benchmark tests as they require libtest. Fixes #24923.
projects / rust.git / log