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.
Remove strictly-unnecessary flags for docker
cc #39035
In addition to `--tty` I've removed `--interactive` as I don't think there's any reason for it to be there (it only hooks up stdin, which shouldn't be used anyway).
If this looks like it's working over a few days then I'll also alter the libc scripts.
r? @alexcrichton
resolve: Do not use "resolve"/"resolution" in error messages
Use less jargon-y wording instead.
`cannot find <struct> <S> in <this scope>` and `cannot find <struct> <S> in <module a::b>` are used for base messages (this also harmonizes nicely with "you can import it into scope" suggestions) and `not found in <this scope>` and `not found in <a::b>` are used for short labels in fall-back case.
I tweaked some other diagnostics to avoid using "resolve" (see, e.g., `librustc_resolve/macros.rs`), but haven't touched messages for imports.
Closes https://github.com/rust-lang/rust/issues/38750
r? @nrc
Fix some typos in Nomicon
I waited a bit before creating this PR in case I find more typos – I didn't.
I've read `CONTRIBUTING.md` but didn't `make check`, and `make doc` takes incredibly long. (Among other things, `make doc` builds llvm from scratch. Not sure if that's intentional.)
std/net/udp: Improve set_nonblocking test
While writing a separate change, I noticed the current test for `UdpSocket::set_nonblocking()` is fairly ineffective.
This fixes the test so that it validates that a correct error is returned on calls to `recv()` when no data is available.
Clarify Extend behaviour wrt existing keys
This seems to be consistent with all the Extend implementations I found, and isn't documented anywhere else afaik.
Implement Display for char Escape*, To*case.
See: rust-lang/rfcs#1848.
A good example of where this is useful would be in the example `print!("{}", 'ß'.to_uppercase())`.
Not sure if this requires a formal RFC, but I decided to write the code for it anyway regardless.
travis: Start uploading artifacts on commits
This commit starts adding the infrastructure for uploading release artifacts
from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a
full release to AppVeyor/Travis in accordance with plans [outlined earlier].
Right now this configures Travis/Appveyor to upload all tarballs in the `dist`
directory, and various images are updated to actually produce tarballs in these
directories. These are nowhere near ready to be actual release artifacts, but
this should allow us to play around with it and test it out. Once this commit
lands we should start seeing artifacts uploaded on each commit.
[outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
This commit starts adding the infrastructure for uploading release artifacts
from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a
full release to AppVeyor/Travis in accordance with plans [outlined earlier].
Right now this configures Travis/Appveyor to upload all tarballs in the `dist`
directory, and various images are updated to actually produce tarballs in these
directories. These are nowhere near ready to be actual release artifacts, but
this should allow us to play around with it and test it out. Once this commit
lands we should start seeing artifacts uploaded on each commit.
[outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
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
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.
syntax: enable attributes and cfg on struct fields
This enables conditional compilation of field initializers in a struct literal, simplifying construction of structs whose fields are themselves conditionally present. For example, the intializer for the constant in the following becomes legal, and has the intuitive effect:
```rust
struct Foo {
#[cfg(unix)]
bar: (),
}
const FOO: Foo = Foo {
#[cfg(unix)]
bar: (),
};
```
It's not clear to me whether this calls for the full RFC process, but the implementation was simple enough that I figured I'd begin the conversation with code.
Fix rustdoc highlighting of `&` and `*`
Whitespace tokens were included, so the span check used with `&` was incorrect, and it was never highlighted as kw-2 (RefKeyword).
The `*` in `*foo` and `*const T` should also be highlighted kw-2, so I added them. Note that this *will* cause mishighlighting of code like `1*2`, but that should have been written `1 * 2`. Same deal with `1&2`.
Do not run outer setup part of benchmarks multiple times to fix issue 20142
Fix#20142
This is my first real rust code, so I expect the quality is quite bad. Please let me know in which ways it is horrible and I'll fix it.
Previously the whole benchmark function was rerun many times, but with this change, only the callback passed to iter is rerun. This improves performances by saving benchmark startup time. The setup used to be called a minimum of 101 times, and now only runs once.
I wasn't sure exactly what should be done for the case where iter is never called, so I left a FIXME for that: currently it does not error, and I added tests to cover that.
I have left the algorithm and statistics unchanged: I don't like how the minimum number of runs is 301 (that's bad for very slow benchmarks) but I consider such changes out of scope for this fix.
