bors [Tue, 14 Jun 2016 12:04:38 +0000 (05:04 -0700)]
Auto merge of #34232 - ollie27:rustdoc_inline, r=alexcrichton
rustdoc: Don't inline #[doc(hidden)] pub use
Currently if a `#[doc(hidden)] pub use` item is inlined the `hidden`
attribute is ignored so the item can appear in the docs. By never inlining
such imports, they can be stripped.
An example in `std` is [`__OsLocalKeyInner`](https://doc.rust-lang.org/nightly/std/thread/struct.__OsLocalKeyInner.html) which clearly should not be documented.
Zack M. Davis [Mon, 13 Jun 2016 03:55:36 +0000 (20:55 -0700)]
edit E0453 long explanation for style, clarity, and citizenship
It turns out that the subsequent lines of the error message comment
should be aligned like this.
The "turns the corresponding compiler warning" language may not be
strictly the most accurate—a lint check isn't the same as a compiler
warning; it emits a compiler warning if it's set to the `warn` level—
but it may be worth glossing over such distinctions in favor of simple,
familar phrasings for the sake of pedagogy; thanks to Guillaume Gomez
for the wording suggestion.
Let's also fix up the introductory clauses of the sentences about how to
fix the error to put a little more emphasis on the fact that the
`forbid` setting was probably there for a reason.
Currently if a `#[doc(hidden)] pub use` item is inlined the `hidden`
attribute is ignored so the item can appear in the docs. By never inlining
such imports, they can be stripped.
bors [Sat, 11 Jun 2016 08:32:44 +0000 (01:32 -0700)]
Auto merge of #34208 - shepmaster:llvm-3.7-linking-intrinsics, r=alexcrichton
Remove linking and intrinsics code made dead by only supporting LLVM 3.7 and up
This is mostly based on Alex's throwaway comment:
> probably reject those that LLVM just doesn't support...
So I'm more than happy to adjust the PR based on how you thought this should look. Also happy to split it into two PRs, one for linking and one for intrinsics.
bors [Sat, 11 Jun 2016 05:41:24 +0000 (22:41 -0700)]
Auto merge of #34002 - jseyfried:strip_tests_in_cfg, r=nrc
Treat `#[test]` like `#[cfg(test)]` in non-test builds
This PR treats `#[test]` like `#[cfg(test)]` in non-test builds. In particular, like `#[cfg(test)]`,
- `#[test]` nodes are stripped during `cfg` processing, and
- `#[test]` is disallowed on non-optional expressions.
bors [Fri, 10 Jun 2016 17:37:35 +0000 (10:37 -0700)]
Auto merge of #34199 - jseyfried:visit_all_attrs, r=nrc
Visit statement and expression attributes in the AST visitor
Currently, these attributes are not visited, so they are not gated feature checked in the post expansion visitor. This only affects crates using `#![feature(stmt_expr_attributes)]`.
r? @nrc
Seo Sanghyeon [Fri, 10 Jun 2016 12:16:44 +0000 (21:16 +0900)]
Rollup merge of #34129 - jviide:from-string-box-error, r=steveklabnik
Remove a gotcha from book/error-handling.md
The book's "Error handling with `Box<Error>`" section talks about `Box<Error>`. In the actual example `Box<Error + Send + Sync>` is used instead so that the corresponding From impls could be used to convert a plain string to an error type. Rust 1.7 added support for conversion from `&str`/`String` to
`Box<Error>`, so this gotcha and later references to it can now be removed.
bors [Fri, 10 Jun 2016 11:50:46 +0000 (04:50 -0700)]
Auto merge of #34178 - shepmaster:llvm-3.7-and-up, r=alexcrichton
Reflect supporting only LLVM 3.7+ in the LLVM wrappers
Based on 12abddb06b681f5c1cb389074b5a35d3e260698f, it appears we can drop support for these older LLVM versions. Hopefully, this will make it slightly easier to support the changes needed for LLVM 3.9.
bors [Fri, 10 Jun 2016 04:29:26 +0000 (21:29 -0700)]
Auto merge of #34046 - Vtec234:fix-atomic-doc, r=steveklabnik
Fix wrong statement in compare_exchange doc
The documentation for `core::sync::atomic::AtomicSomething::compare_exchange` contains a wrong, or imprecise, statement about the return value. It goes:
The return value is a result indicating whether the new value was written and containing
the previous value. On success this value is guaranteed to be equal to `new`.
In the second sentence, `this value` is gramatically understood as referring to `return value` from the first sentence. Due to how CAS works, the returned value is always what was in the atomic variable _before_ the operation occurred, not what was written into it during the operation. Hence, the fixed doc should say:
The return value is a result indicating whether the new value was written and containing
the previous value. On success this value is guaranteed to be equal to `current`.
This version is confirmed by the runnable examples in variants of `AtomicSomething`, e.g.
where the returned value is `Ok(current)`. This PR fixes all occurrences of this bug I could find.
An alternative solution would be to modify the second sentence so that it refers to the value _written_ into the Atomic rather than what was there before, in which case it would be correct. Example alternative formulation:
On success the value written into the `bool`/`usize`/`whatever` is guaranteed to be equal to `new`.
bors [Thu, 9 Jun 2016 22:48:37 +0000 (15:48 -0700)]
Auto merge of #34095 - petrochenkov:pathir2, r=jseyfried
Improvements to pattern resolution + some refactoring
Continuation of https://github.com/rust-lang/rust/pull/33929
First commit is a careful rewrite of `resolve_pattern`, pattern path resolution and new binding creation logic is factored out in separate functions, some minor bugs are fixed. Also, `resolve_possibly_assoc_item` doesn't swallow modules now.
Later commits are refactorings, see the comment descriptions.
I intend to continue this work later with better support for `Def::Err` in patterns in post-resolve stages and cleanup of pattern resolution code in type checker.
bors [Thu, 9 Jun 2016 14:13:34 +0000 (07:13 -0700)]
Auto merge of #33895 - AndrewBrinker:master, r=steveklabnik
Rewrote "How Safe and Unsafe Interact" Nomicon chapter.
The previous version of the chapter covered a lot of ground, but was a little meandering and hard to follow at times. This draft is intended to be clearer and more direct, while still providing the same information as the previous version.
Use it instead of a `panic` for inexhaustive matches and correct the
comment. I think we trust our match-generation algorithm enough to
generate these blocks, and not generating an `unreachable` means that
LLVM won't optimize `match void() {}` to an `unreachable`.
bors [Thu, 9 Jun 2016 11:24:50 +0000 (04:24 -0700)]
Auto merge of #34109 - pnkfelix:fix-issue-34101, r=arielb1
Fix issue #34101
Fix issue #34101: do not track subcontent of type with dtor nor gather flags for untracked content.
(Includes a regression test, which needed to go into `compile-fail/`
due to weaknesses when combining `#[deny(warnings)]` with
`tcx.sess.span_warn(..)`)
bors [Thu, 9 Jun 2016 08:35:26 +0000 (01:35 -0700)]
Auto merge of #34108 - jseyfried:refactor_prelude_injection, r=nrc
Refactor away the prelude injection fold
Instead, just inject `#[prelude_import] use [core|std]::prelude::v1::*;` at the crate root while injecting `extern crate [core|std];` and process `#[no_implicit_prelude]` attributes in `resolve`.
bors [Thu, 9 Jun 2016 05:45:35 +0000 (22:45 -0700)]
Auto merge of #34032 - jseyfried:load_macros_in_expansion, r=nrc
Support `#[macro_use]` on macro-expanded crates
This PR loads macros from `#[macro_use]` crates during expansion so that
- macro-expanded `#[macro_use]` crates work (fixes #33936, fixes #28071), and
- macros imported from crates have the same scope as macros imported from modules.
This is a [breaking-change]. For example, this will break:
```rust
macro_rules! m {
() => { #[macro_use(foo)] extern crate core; } //~ ERROR imported macro not found
}
m!();
```
Also, this will break:
```rust
macro_rules! try { () => {} }
// #[macro_use] mod bar { macro_rules! try { ... } } //< ... just like this would ...
fn main() { try!(); } //< ... making this an error
```
projects / rust.git / log