bors [Fri, 18 Dec 2015 12:23:54 +0000 (12:23 +0000)]
Auto merge of #30286 - oli-obk:const_error_span, r=nikomatsakis
previously the error was erased and a `non-const path` error was emitted at the location of the field access instead of at the overflow location (as can be seen in the playground: http://is.gd/EuAF5F )
bors [Fri, 18 Dec 2015 03:05:02 +0000 (03:05 +0000)]
Auto merge of #30414 - alexcrichton:fix-cross-builds, r=brson
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
Steve Klabnik [Thu, 17 Dec 2015 19:47:14 +0000 (14:47 -0500)]
Rollup merge of #30439 - swooster:swooster-nomicon-patch-1, r=steveklabnik
The Rustonomicon's Lifetimes chapter uses the idiom "big ask", which is obscure compared to "tall order" (check [Google ngrams](https://books.google.com/ngrams/graph?content=big+ask%2C+tall+order&year_start=1800)). Also, it's easily mistaken for a typo; either "a big task" or "a big thing to ask" could plausibly work there.
Steve Klabnik [Thu, 17 Dec 2015 19:47:13 +0000 (14:47 -0500)]
Rollup merge of #30404 - Shiney:ImprovedStackHeap, r=steveklabnik
…entation clearer
I could not use colors as suggested for #29854 because Github doesn't support these in markdown, however this solution may be better for color-blind readers.
bors [Thu, 17 Dec 2015 18:21:25 +0000 (18:21 +0000)]
Auto merge of #30325 - jseyfried:fixes_30078, r=nrc
This fixes a bug in which unused imports can get wrongly marked as used when checking for unused qualifications in `resolve_path` (issue #30078), and it removes unused imports that were previously undetected because of the bug.
Steve Wooster [Thu, 17 Dec 2015 17:40:02 +0000 (09:40 -0800)]
Change "big ask" to "tall order" in Rustonomicon.
The Rustonomicon's Lifetimes chapter uses the idiom "big ask", which is obscure compared to "tall order" (check Google ngrams). Also, it's easily mistaken for a typo; either "a big task" or "a big thing to ask" could plausibly work there.
bors [Wed, 16 Dec 2015 22:53:19 +0000 (22:53 +0000)]
Auto merge of #30341 - pnkfelix:call-site-scope, r=nikomatsakis
Ensure borrows of fn/closure params do not outlive invocations.
Does this by adding a new CallSiteScope to the region (or rather code extent) hierarchy, which outlives even the ParameterScope (which in turn outlives the DestructionScope of a fn/closure's body).
bors [Wed, 16 Dec 2015 20:22:07 +0000 (20:22 +0000)]
Auto merge of #29962 - aturon:coherence-errors, r=nmatsakis
Currently, a coherence error based on overlapping impls simply mentions
the trait, and points to the two conflicting impls:
```
error: conflicting implementations for trait `Foo`
```
With this commit, the error will include all input types to the
trait (including the `Self` type) after unification between the
overlapping impls. In other words, the error message will provide
feedback with full type details, like:
```
error: conflicting implementations of trait `Foo<u32>` for type `u8`:
```
When the `Self` type for the two impls unify to an inference variable,
it is elided in the output, since "for type `_`" is just noise in that
case.
Aaron Turon [Tue, 1 Dec 2015 19:26:47 +0000 (11:26 -0800)]
Provide overlapping types for coherence errors
Currently, a coherence error based on overlapping impls simply mentions
the trait, and points to the two conflicting impls:
```
error: conflicting implementations for trait `Foo`
```
With this commit, the error will include all input types to the
trait (including the `Self` type) after unification between the
overlapping impls. In other words, the error message will provide
feedback with full type details, like:
```
error: conflicting implementations of trait `Foo<u32>` for type `u8`:
```
When the `Self` type for the two impls unify to an inference variable,
it is elided in the output, since "for type `_`" is just noise in that
case.
Alex Crichton [Wed, 16 Dec 2015 16:06:27 +0000 (08:06 -0800)]
mk: Use the right llvmdeps.rs file for cross build
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
Rollup merge of #30368 - arielb1:region-unification-2, r=nikomatsakis
Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
Rollup merge of #30320 - nrc:err-names, r=@nikomatsakis
We can now handle name resolution errors and get past type checking (if we're a bit lucky). This is the first step towards doing code completion for partial programs (we need error recovery in the parser and early access to save-analysis).
bors [Wed, 16 Dec 2015 10:09:36 +0000 (10:09 +0000)]
Auto merge of #30300 - sanxiyn:syntax-ext, r=nikomatsakis
This reduces iteration time (`make rustc-stage1`) for moved syntax extensions from 11 minutes to 3 minutes on my machine.
Because of the signature change, this is a [breaking-change] for people directly calling `expand_crate`. I think it is rare: from GitHub search, only case I found is [glassful](https://github.com/kmcallister/glassful).
The attributes `deprecated` and `rustc_deprecated` are completely independent in this implementation and it leads to some noticeable code duplication. Representing `deprecated` as
```
Stability {
level: Stable { since: "" },
feature: "",
depr: Some(Deprecation),
}
```
or, contrariwise, splitting rustc_deprecation from stability makes most of the duplication go away.
I can do this refactoring, but before doing it I must be sure, that further divergence of `deprecated` and `rustc_deprecated` is certainly not a goal.
Ensure borrows of fn/closure params do not outlive invocations.
resolve_lifetime.rs: Switch from BlockScope to FnScope in ScopeChain
construction. Lifetimes introduced by a fn signature are scoped to the
call-site for that fn. (Note `add_scope_and_walk_fn` must only add
FnScope for the walk of body, *not* of the fn signature.)
region.rs: Introduce new CodeExtentData::CallSiteScope variant. Use
CodeExtentData as the cx.parent, rather than just a NodeId. Change
DestructionScopeData to CallSiteScopeData.
regionck.rs: Thread call_site_scope via Rcx; constrain fn return
values.
bors [Tue, 15 Dec 2015 04:21:53 +0000 (04:21 +0000)]
Auto merge of #30233 - retep998:where-in-the-world-is-windows-sdk, r=alexcrichton
What I've done here is try to make the code match what vcvars does much more closely. It now chooses which SDK to find based on the version of MSVC that it found. It also bases the decision of whether to find all the things on whether `VCINSTALLDIR` has been set, which is more likely to have only been set by an invocation of vcvars, unlike previously where it would do some things only if `LIB` wasn't set even though there was a valid use case for libraries to add themselves to `LIB` without having invoked vcvars.
There are still some debug `println!`s so people can test the PR and make sure it works correctly on various setups.
It supports VS 2015, 2013, and 2012. People who want to use versions of VS older (or newer) than that will have to manually invoke the appropriate vcvars bat file to set the proper environment variables themselves.
bors [Mon, 14 Dec 2015 19:14:37 +0000 (19:14 +0000)]
Auto merge of #27937 - DiamondLovesYou:llvm-root-and-shared, r=alexcrichton
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
bors [Mon, 14 Dec 2015 13:48:41 +0000 (13:48 +0000)]
Auto merge of #29735 - Amanieu:asm_indirect_constraint, r=pnkfelix
This PR reverts #29543 and instead implements proper support for "=*m" and "+*m" indirect output operands. This provides a framework on top of which support for plain memory operands ("m", "=m" and "+m") can be implemented.
This also fixes the liveness analysis pass not handling read/write operands correctly.
Richard Diamond [Sat, 22 Aug 2015 04:43:56 +0000 (23:43 -0500)]
Better support for `--llvm-root`.
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
bors [Sun, 13 Dec 2015 15:22:03 +0000 (15:22 +0000)]
Auto merge of #30342 - salty-horse:doc_links, r=steveklabnik
Many of the structs in `str` that are used as part of its methods do not have links to the methods.
This is especially annoying when a Google search drops you into the documentation of the struct, when you really wanted to get to the method of the same name.
bors [Sun, 13 Dec 2015 07:56:03 +0000 (07:56 +0000)]
Auto merge of #30314 - fhahn:issue-30299-missing-fields, r=pnkfelix
This PR for #30299 adds the name of the type where the field is missing.
The span that's used for the error seems correct. What may be confusing is when the initializer with the missing field contains other intializers. These are then included in the span. For example, consider the following listing.
struct A {
a1: i32,
a2: B,
}
struct B {
b1: i32,
b2: i32
}
fn main() {
let x = A {
a2: B {
b1: 1,
b2: 1
},
};
}
It will display the following code snippet along with the message that field `a2` is missing:
let x = A {
a2: B {
b1: 1,
b2: 1
},
};
By adding the name of the type it's clearer where the field is missing.
bors [Sun, 13 Dec 2015 05:18:19 +0000 (05:18 +0000)]
Auto merge of #30324 - jseyfried:unfix_30159, r=nrc
r? @nrc
Since PR #30294 unintentionally fixed issue #30159, it can cause breakage for a different reason than I originally stated in the PR (see #30159, I characterized the issue precisely there).
This commit limits the scope of the breakage to what I originally stated in the PR by "unfixing" the backwards incompatible part of #30159.
I think fixing #30159 has enough potential for breakage to warrant a crater run. If you disagree, I can cancel this PR, leaving it fixed.
bors [Sun, 13 Dec 2015 01:53:06 +0000 (01:53 +0000)]
Auto merge of #30310 - mbrubeck:doc-vec-bounds, r=steveklabnik
r? @steveklabnik
Currently neither the API docs nor the book clearly explain that out-of-bounds array indexing causes a panic. Since this is fairly important and seems to surprise a number of new Rust programmers, I think it's worth adding to both places. (But if you think it would be better to put this info in the API docs only, that's fine too.)
Some specific things I'd like feedback on:
* The new text here talks about panicking, which hasn't been formally introduced at this point in chapter 5 (though it has been mentioned in previous sections too).
* Similarly the `Vec::get` example uses `Option<T>` which hasn't been fully introduced yet. Should we leave out this example?
bors [Sat, 12 Dec 2015 18:02:43 +0000 (18:02 +0000)]
Auto merge of #30347 - rkruppe:misc-dec2flt-cleanup, r=alexcrichton
The landing of #30182, specifically the removal of float `from_str_radix`, allowed the refactoring in the middle commit. While I was at it, I also crossed two other nits off my TODO list.
Ariel Ben-Yehuda [Sat, 12 Dec 2015 17:02:33 +0000 (19:02 +0200)]
fix dropck performance regression
Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
bors [Sat, 12 Dec 2015 06:18:44 +0000 (06:18 +0000)]
Auto merge of #30242 - arielb1:region-unification, r=nikomatsakis
Fixes #29844
I would prefer to
(a) make some performance measurements
(b) use the unification table in a few more places
before committing further, but this is probably good enough for beta.