bors [Thu, 28 May 2015 02:17:48 +0000 (02:17 +0000)]
Auto merge of #25824 - alexcrichton:fix-deadlocking-test-on-windows, r=nikomatsakis
Windows tests can often deadlock if a child thread continues after the main
thread and then panics, and a `println!` executed in a child thread after the
main thread has exited is at risk of panicking.
Rollup merge of #25792 - koobs:patch-1, r=alexcrichton
Currently, there are two conditional blocks that exist to check for "clang or gcc"
On line 866:
```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
and on line 1019:
```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set.
The expected behaviour is to honour user-flags, in this case CC.
Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
bors [Wed, 27 May 2015 17:25:00 +0000 (17:25 +0000)]
Auto merge of #25799 - alexcrichton:fix-link-in-mk, r=luqmana
The changes scaled back in 4cc025d8 were a little too aggressive and broke a
bunch of cross compilations by not defining the `LINK_$(1)` variable for all
targets. This commit ensures that the variable is defined for all targets by
defaulting it to the normal compiler if it's not already defined (it's only
defined specially for MSVC).
Alex Crichton [Wed, 27 May 2015 16:15:19 +0000 (09:15 -0700)]
test: Join child threads on windows in tests
Windows tests can often deadlock if a child thread continues after the main
thread and then panics, and a `println!` executed in a child thread after the
main thread has exited is at risk of panicking.
bors [Wed, 27 May 2015 10:21:11 +0000 (10:21 +0000)]
Auto merge of #25762 - dotdash:codegen_test, r=alexcrichton
The current codegen tests only compare IR line counts between similar
rust and C programs, the latter getting compiled with clang. That looked
like a good idea back then, but actually things like lifetime intrinsics
mean that less IR isn't always better, so the metric isn't really
helpful.
Instead, we can start doing tests that check specific aspects of the
generated IR, like attributes or metadata. To do that, we can use LLVM's
FileCheck tool which has a number of useful features for such tests.
To start off, I created some tests for a few things that were recently
added and/or broken.
Björn Steinbrink [Sun, 24 May 2015 16:07:52 +0000 (18:07 +0200)]
Revamp codegen tests to check IR quality instead of quantity
The current codegen tests only compare IR line counts between similar
rust and C programs, the latter getting compiled with clang. That looked
like a good idea back then, but actually things like lifetime intrinsics
mean that less IR isn't always better, so the metric isn't really
helpful.
Instead, we can start doing tests that check specific aspects of the
generated IR, like attributes or metadata. To do that, we can use LLVM's
FileCheck tool which has a number of useful features for such tests.
To start off, I created some tests for a few things that were recently
added and/or broken.
bors [Wed, 27 May 2015 07:14:45 +0000 (07:14 +0000)]
Auto merge of #25791 - barosl:use-paths-as-items, r=alexcrichton
Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
bors [Wed, 27 May 2015 00:42:55 +0000 (00:42 +0000)]
Auto merge of #25713 - Stebalien:pattern, r=alexcrichton
Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
bors [Tue, 26 May 2015 23:10:06 +0000 (23:10 +0000)]
Auto merge of #25688 - nham:E0055_E0192, r=alexcrichton
- Adds explanations for E0055, E0089, E0192, E0261-E0263, E0318
- Improves explanations for E0250, E0368, E0372.
- Converts 15 diagnostics to have error codes (E0380-E0394). Adds an explanation for E0380.
- The E0087-E0090 messages currently look like "expected {} parameter(s) found {} parameter(s)". This changes them to either use "parameter" or "parameters", based on the number.
bors [Tue, 26 May 2015 18:30:42 +0000 (18:30 +0000)]
Auto merge of #25593 - nham:E0210_E0326, r=alexcrichton
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Alex Crichton [Tue, 26 May 2015 16:48:24 +0000 (09:48 -0700)]
mk: Ensure LINK_$(1) is defined for all targets
The changes scaled back in 4cc025d8 were a little too aggressive and broke a
bunch of cross compilations by not defining the `LINK_$(1)` variable for all
targets. This commit ensures that the variable is defined for all targets by
defaulting it to the normal compiler if it's not already defined (it's only
defined specially for MSVC).
bors [Tue, 26 May 2015 16:58:07 +0000 (16:58 +0000)]
Auto merge of #25091 - quantheory:trait_associated_const_fixes, r=nikomatsakis
Closes #25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
bors [Tue, 26 May 2015 14:08:24 +0000 (14:08 +0000)]
Auto merge of #25411 - alexcrichton:issue-18913, r=brson
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Alex Crichton [Thu, 14 May 2015 18:53:37 +0000 (11:53 -0700)]
rustc_back: Don't pass 'u' to ar invocations
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
bors [Tue, 26 May 2015 12:15:30 +0000 (12:15 +0000)]
Auto merge of #25785 - arielb1:cleanup-201505, r=eddyb
The caching essentially eliminates "stability checking" time (my attempt to clean-up junk got tangled up with stability, so I added the caching while I was at it).
bors [Tue, 26 May 2015 09:49:36 +0000 (09:49 +0000)]
Auto merge of #25778 - econoplas:master, r=pnkfelix
A regression was introduced by commit https://github.com/rust-lang/rust/commit/7b1916d25347913fce3e336517ef22025ccd875f #25612. Negative signed integer literals less than -9223372036854775808i64 were no longer properly reported as #[warn(overflowing_literals)].
Also adding missing test cases to test/compile-fail/lint-type-overflow.rs which could have detected the regression.
Further explanation:
The expression `(negative && v > max as u64 + 1)` relies on the fact that algebraically speaking `-min == max + 1` to avoid negation and removing the need for `min` completely.
If i128 or i256 are ever added, it should also work for these types without requiring a change to `min != i64::MIN &&` also simplifying maintenance.
Barosl Lee [Tue, 26 May 2015 02:27:15 +0000 (11:27 +0900)]
Associate each path in a `use` declaration with the item in the AST map
Currently, for `use` declarations with multiple paths, only the `use`
item itself is saved in the AST map, not the individual path nodes. This
can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in
`ImportResolver::check_for_conflicting_import()`.
Kubilay Kocak [Tue, 26 May 2015 08:23:33 +0000 (18:23 +1000)]
Remove redundant compiler check. Allow CC override
Currently, there are two conditional blocks that exist to check for "clang or gcc"
On line 866:
```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
and on line 1019:
```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set.
The expected behaviour is to honour user-flags, in this case CC.
Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
bors [Mon, 25 May 2015 19:52:45 +0000 (19:52 +0000)]
Auto merge of #25698 - mdinger:flat_map, r=steveklabnik
I'm not sure why `core` is on but it's blocking the playpen. Doesn't seem to be needed but I'm not sure. It's not on the playpen template and playpen works on release and nightly.
bors [Mon, 25 May 2015 18:18:11 +0000 (18:18 +0000)]
Auto merge of #25742 - thombles:tk/StringCoercion, r=steveklabnik
A few of us [over on the forum](https://users.rust-lang.org/t/string-type-coercion-in-rust/1439) have been tripped up by this distinction, which I don't think is mentioned. It's kind of logical if you read the "Deref coercions" page and squint a bit but I think it would be nice to explain it directly. Here's one way we could clarify it.
Ulrik Sverdrup [Mon, 25 May 2015 13:06:38 +0000 (15:06 +0200)]
rustdoc: Fix associated types in signatures
Functions such as `fn foo<I: Iterator>(x: I::Item)` would not
render correctly and displayed `I` instead of `I::Item`. Same thing
with `I::Item` appearing in where bounds.
econoplas [Mon, 25 May 2015 13:42:16 +0000 (07:42 -0600)]
- Fix regression of literal out of range check for negative i64 values which was introduced by commit 7b1916d25347913fce3e336517ef22025ccd875f.
- Add missing test cases to test/compile-fail/lint-type-overflow.rs which would have detected the regression.
bors [Mon, 25 May 2015 03:40:31 +0000 (03:40 +0000)]
Auto merge of #25761 - ralexstokes:master, r=steveklabnik
Typo in explanation of difference between stack and heap values.
`baz` is called at the end of a call to `bar` inside another call to `foo`. `baz` takes a copy of the value `e` which should have a value of 9 if following the rest of the stack trace.
bors [Sun, 24 May 2015 11:12:34 +0000 (11:12 +0000)]
Auto merge of #25609 - nikomatsakis:const-fn, r=pnkfelix
This is a port of @eddyb's `const-fn` branch. I rebased it, tweaked a few things, and added tests as well as a feature gate. The set of tests is still pretty rudimentary, I'd appreciate suggestions on new tests to write. Also, a double-check that the feature-gate covers all necessary cases.
One question: currently, the feature-gate allows the *use* of const functions from stable code, just not the definition. This seems to fit our usual strategy, and implies that we might (perhaps) allow some constant functions in libstd someday, even before stabilizing const-fn, if we were willing to commit to the existence of const fns but found some details of their impl unsatisfactory.
projects / rust.git / log