rustbuild: Skip the build_helper crate in tests
I've been noticing some spurious recompiles of the final stage on Travis lately
and in debugging them I found a case where we were a little to eager to update
a stamp file due to the build_helper library being introduced during the testing
phase.
Part of the rustbuild system detects when libstd is recompiled and automatically
cleans out future directories to ensure that dirtyness propagation works. To do
this rustbuild doesn't know the artifact name of the standard library so it just
probes everything in the target directory, looking to see if anything changed.
The problem here happened where:
* First, rustbuild would compile everything (a normal build)
* Next, rustbuild would run all tests
* During testing, the libbuild_helper library was introduced into the target
directory, making it look like a change happened because a file is newer
than the newest was before
* Detecting a change, the next compilation would then cause rustbuild to clean
out old artifacts and recompile everything again.
This commit fixes this problem by correcting rustbuild to just not test the
build_helper crate at all. This crate doesn't have any unit tests, nor is it
intended to. That way the target directories should stay the same throughout
testing after a previous build.
Use multiline Diagnostic for "relevant impl" list
Provide the following output:
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
<Bar as Foo<i8>>
<Bar as Foo<i16>>
<Bar as Foo<i32>>
<Bar as Foo<u8>>
and 2 others
error: aborting due to previous error
```
instead of
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
= help: <Bar as Foo<i8>>
= help: <Bar as Foo<i16>>
= help: <Bar as Foo<i32>>
= help: <Bar as Foo<u8>>
= help: and 2 others
error: aborting due to previous error
```
This marks the pushpop_unsafe feature as removed inside the feature_gate.
It was added in commit 1829fa5199 and then
removed again in commit d399098fd8 .
Seems that the second commit forgot to mark it as removed in feature_gate.rs.
This enables us to remove another element from the whitelist of non gate
tested unstable lang features (issue #39059).
This removes the safe_suggestion feature from feature_gate.rs.
It was added in commit 164f0105bb
and then removed again in commit c11fe553df .
As the removal was in the same PR #38099 as the addition, we don't move it to
the "removed" section.
Removes an element from the whitelist of non gate tested unstable lang features (issue #39059).
rustbuild: Actually don't build stage0 target rustc
This was attempted in #38853 but erroneously forgot one more case of where the
compiler was compiled. This commit fixes that up and adds a test to ensure this
doesn't sneak back in.
incr.comp.: Add some caching to Predecessors construction.
This speeds up the "serialize dep graph" pass for libsyntax from 45 secs to 15 secs on my machine. Still far from ideal, but things will get better when we change the metadata hashing strategy.
The `CACHING_THRESHOLD` value of 60 has been arrived at experimentally. It seemed to give the best speedup.
r? @nikomatsakis
Fix two const-eval issues related to i128 negation
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.
The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.
Fixes#38987
expect_err for Result.
This adds an `expect_err` method to `Result`. Considering how `unwrap_err` already exists, this seems to make sense. Inconsistency noted in Manishearth/rust-clippy#1435.
save-analysis: handle paths in type/trait context more correctly
TBH, this is still not perfect, witness the FIXME, but it is an improvement. In particular it means we get information about trait references in impls.
These switch statements cover all possible values, so the default case
is dead code (it contains an llvm_unreachable anyway), triggering a
-Wcovered-switch-default warning. Moving the unreachable after the
switch resolves these warnings. This keeps the build output clean.
trans: Treat generics like regular functions, not like #[inline] function, during CGU partitioning
This PR makes generics be treated just like regular functions during CGU partitioning:
+ the function instantiation is placed in a codegen unit based on the function's DefPath,
+ unless it is marked with `#[inline]` -- which causes a private copy of the function to be placed in every referencing codegen unit.
This has the following effects:
+ Multi codegen unit builds will become faster because code for generic functions is duplicated less.
+ Multi codegen unit builds might have lower runtime performance, since generics are not available for inlining automatically any more.
+ Single codegen unit builds are not affected one way or the other.
This partitioning scheme is particularly good for incremental compilation as it drastically reduces the number of false positives during codegen unit invalidation.
I'd love to have a benchmark suite for estimating the effect on runtime performance for changes like this one.
r? @nikomatsakis
cc @rust-lang/compiler
Make tidy check for lang gate tests
Add gate tests to the checks that tidy performs. Excerpt from the commit message of the main commit:
Require compile-fail tests for new lang features
Its non trivial to test lang feature gates, and people
forget to add such tests. So we extend the features lint
of the tidy tool to ensure that all new lang features
contain a new compile-fail test.
Of course, one could drop this requirement and just
grep all tests in run-pass for #![feature(abc)] and
then run this test again, removing the mention,
requiring that it fails.
But this only tests for the existence of a compilation
failure. Manual tests ensure that also the correct lines
spawn the error, and also test the actual error message.
For library features, it makes no sense to require such
a test, as here code is used that is generic for all
library features.
The tidy lint extension now checks the compile-fail test suite for occurences of "gate-test-X" where X is a feature. Alternatively, it also accepts file names with the form "feature-gate-X.rs". If a lang feature is found that has no such check, we emit a tidy error.
I've applied the markings to all tests I could find in the test suite. I left a small (20 elements) whitelist of features that right now have no gate test, or where I couldn't find one. Once this PR gets merged, I'd like to close issue #22820 and open a new one on suggestion of @nikomatsakis to track the removal of all elements from that whitelist (already have a draft). Writing such a small test can be a good opportunity for a first contribution, so I won't touch it (let others have the fun xD).
cc @brson , @pnkfelix (they both discussed about this in the issue linked above).
travis: Attempt to debug OSX linker segfaults
This commit attempts to debug the segfaults that we've been seeing on OSX on
Travis. I have no idea what's going on here mostly, but let's try to look at
core dumps and get backtraces to see what's going on. This commit itself is
mostly a complete shot in the dark, I'm not sure if this even works...
cc #38878
LLVM usually prefers using memcpys over direct loads/store of first
class aggregates. The check in type_is_immediate to mark certain small
structs was originally part of the code to handle such immediates in
function arguments, and it had a counterpart in load_ty/store_ty to
actually convert small aggregates to integers.
But since then, the ABI handling has been refactored and takes care of
converting small aggregates to integers. During that refactoring, the
code to handle small aggregates in load_ty/store_ty has been removed,
and so we accidentally started using loads/stores on FCA values.
Since type_is_immediate() is no longer responsible for ABI-related
conversions, and using a memcpy even for small aggregates is usually
better than performing a FCA load/store, we can remove that code part
and only handle simple types as immediates there.
This integrates PR #38906 onto this branch.
Fixes#38906.
I've been noticing some spurious recompiles of the final stage on Travis lately
and in debugging them I found a case where we were a little to eager to update
a stamp file due to the build_helper library being introduced during the testing
phase.
Part of the rustbuild system detects when libstd is recompiled and automatically
cleans out future directories to ensure that dirtyness propagation works. To do
this rustbuild doesn't know the artifact name of the standard library so it just
probes everything in the target directory, looking to see if anything changed.
The problem here happened where:
* First, rustbuild would compile everything (a normal build)
* Next, rustbuild would run all tests
* During testing, the libbuild_helper library was introduced into the target
directory, making it look like a change happened because a file is newer
than the newest was before
* Detecting a change, the next compilation would then cause rustbuild to clean
out old artifacts and recompile everything again.
This commit fixes this problem by correcting rustbuild to just not test the
build_helper crate at all. This crate doesn't have any unit tests, nor is it
intended to. That way the target directories should stay the same throughout
testing after a previous build.
Provide the following output:
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
<Bar as Foo<i8>>
<Bar as Foo<i16>>
<Bar as Foo<i32>>
<Bar as Foo<u8>>
and 2 others
error: aborting due to previous error
```
instead of
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
= help: <Bar as Foo<i8>>
= help: <Bar as Foo<i16>>
= help: <Bar as Foo<i32>>
= help: <Bar as Foo<u8>>
= help: and 2 others
error: aborting due to previous error
```
