Auto merge of #43367 - alexcrichton:remove-inline-always, r=sfackler
std: Cut down #[inline] annotations where not necessary
This PR cuts down on a large number of `#[inline(always)]` and `#[inline]`
annotations in libcore for various core functions. The `#[inline(always)]`
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally `#[inline]` is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.
Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to
0.7s.
Auto merge of #43344 - tlively:wasm-debug, r=alexcrichton
Pass debugging arguments to emcc
Tells emcc to enable assertions and debugging information for
wasm32-experimental-emscripten. This makes the codegen issues caused by
LLVM bug 33824 manifest more frequently at runtime and improves the wasm
debugging experience.
Auto merge of #43323 - perryprog:master, r=estebank
Less verbose output for unused arguments
Closes #37718
This is my first contribution to rust, so sorry if I'm missing anything!
The output now looks like this:
<img width="831" alt="screen shot 2017-07-18 at 5 01 32 pm" src="https://user-images.githubusercontent.com/12972285/28347566-dbfa9962-6c05-11e7-8730-c2e8062a04cc.png">
It's not the prettiest, but whenever #41850 gets resolved, this should be able to be improved.
**EDIT:** This also does not seem
r? @Mark-Simulacrum
Auto merge of #42973 - zackmdavis:json_byte_position_to_start_at_top_of_file, r=nrc
make JSON error byte position start at top of file
The `hi` and `lo` offsets in a span are relative to a `CodeMap`, but this
doesn't seem to be terribly useful for tool consumers who don't have the
codemap, but might want the byte offset within an actual file?
I couldn't get @killercup's [example](https://github.com/rust-lang/rust/issues/35164#issuecomment-301436519) to run, perhaps due to the limitations of the merely-stage-1 compiler that I built (error was `libproc_macro-456500c7095d8fbe.so: cannot open shared object file: No such file or directory`)??—but a dummy project confirms that the byte offsets have successfully been changed to be file-relative—
**Before:**
```
$ cargo run --message-format json
Compiling byte_json v0.1.0 (file:///home/ubuntu/byte_json)
{"message":{"children":[{"children":[],"code":null,"level":"note","message":"#[warn(dead_code)] on by default","rendered":null,"spans":[]}],"code":null,"level":"warning","message":"function is never used: `rah`","rendered":null,"spans":[{"byte_end":100,"byte_start":67,"column_end":2,"column_start":1,"expansion":null,"file_name":"src/foo.rs","is_primary":true,"label":null,"line_end":5,"line_start":3,"suggested_replacement":null,"text":[{"highlight_end":11,"highlight_start":1,"text":"fn rah() {"},{"highlight_end":21,"highlight_start":1,"text":" println!(\"rah!\")"},{"highlight_end":2,"highlight_start":1,"text":"}"}]}]},"package_id":"byte_json 0.1.0 (path+file:///home/ubuntu/byte_json)","reason":"compiler-message","target":{"crate_types":["bin"],"kind":["bin"],"name":"byte_json","src_path":"/home/ubuntu/byte_json/src/main.rs"}}
{"message":{"children":[{"children":[],"code":null,"level":"note","message":"#[warn(dead_code)] on by default","rendered":null,"spans":[]}],"code":null,"level":"warning","message":"function is never used: `alas`","rendered":null,"spans":[{"byte_end":137,"byte_start":102,"column_end":2,"column_start":1,"expansion":null,"file_name":"src/bar.rs","is_primary":true,"label":null,"line_end":3,"line_start":1,"suggested_replacement":null,"text":[{"highlight_end":12,"highlight_start":1,"text":"fn alas() {"},{"highlight_end":22,"highlight_start":1,"text":" println!(\"alas\");"},{"highlight_end":2,"highlight_start":1,"text":"}"}]}]},"package_id":"byte_json 0.1.0 (path+file:///home/ubuntu/byte_json)","reason":"compiler-message","target":{"crate_types":["bin"],"kind":["bin"],"name":"byte_json","src_path":"/home/ubuntu/byte_json/src/main.rs"}}
{"features":[],"filenames":["/home/ubuntu/byte_json/target/debug/byte_json"],"fresh":false,"package_id":"byte_json 0.1.0 (path+file:///home/ubuntu/byte_json)","profile":{"debug_assertions":true,"debuginfo":2,"opt_level":"0","overflow_checks":true,"test":false},"reason":"compiler-artifact","target":{"crate_types":["bin"],"kind":["bin"],"name":"byte_json","src_path":"/home/ubuntu/byte_json/src/main.rs"}}
Finished dev [unoptimized + debuginfo] target(s) in 0.36 secs
Running `target/debug/byte_json`
Hello, world!
```
**After:**
```
$ RUSTC=../rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc cargo run --message-format json
Compiling byte_json v0.1.0 (file:///home/ubuntu/byte_json)
{"message":{"children":[{"children":[],"code":null,"level":"note","message":"#[warn(dead_code)] on by default","rendered":null,"spans":[]}],"code":null,"level":"warning","message":"function is never used: `rah`","rendered":null,"spans":[{"byte_end":35,"byte_start":2,"column_end":2,"column_start":1,"expansion":null,"file_name":"src/foo.rs","is_primary":true,"label":null,"line_end":5,"line_start":3,"suggested_replacement":null,"text":[{"highlight_end":11,"highlight_start":1,"text":"fn rah() {"},{"highlight_end":21,"highlight_start":1,"text":" println!(\"rah!\")"},{"highlight_end":2,"highlight_start":1,"text":"}"}]}]},"package_id":"byte_json 0.1.0 (path+file:///home/ubuntu/byte_json)","reason":"compiler-message","target":{"crate_types":["bin"],"kind":["bin"],"name":"byte_json","src_path":"/home/ubuntu/byte_json/src/main.rs"}}
{"message":{"children":[{"children":[],"code":null,"level":"note","message":"#[warn(dead_code)] on by default","rendered":null,"spans":[]}],"code":null,"level":"warning","message":"function is never used: `alas`","rendered":null,"spans":[{"byte_end":35,"byte_start":0,"column_end":2,"column_start":1,"expansion":null,"file_name":"src/bar.rs","is_primary":true,"label":null,"line_end":3,"line_start":1,"suggested_replacement":null,"text":[{"highlight_end":12,"highlight_start":1,"text":"fn alas() {"},{"highlight_end":22,"highlight_start":1,"text":" println!(\"alas\");"},{"highlight_end":2,"highlight_start":1,"text":"}"}]}]},"package_id":"byte_json 0.1.0 (path+file:///home/ubuntu/byte_json)","reason":"compiler-message","target":{"crate_types":["bin"],"kind":["bin"],"name":"byte_json","src_path":"/home/ubuntu/byte_json/src/main.rs"}}
{"features":[],"filenames":["/home/ubuntu/byte_json/target/debug/byte_json"],"fresh":false,"package_id":"byte_json 0.1.0 (path+file:///home/ubuntu/byte_json)","profile":{"debug_assertions":true,"debuginfo":2,"opt_level":"0","overflow_checks":true,"test":false},"reason":"compiler-artifact","target":{"crate_types":["bin"],"kind":["bin"],"name":"byte_json","src_path":"/home/ubuntu/byte_json/src/main.rs"}}
Finished dev [unoptimized + debuginfo] target(s) in 2.59 secs
Running `target/debug/byte_json`
Hello, world!
```
Zack M. Davis [Thu, 29 Jun 2017 19:07:30 +0000 (12:07 -0700)]
make JSON error byte position start at top of file
The `hi` and `lo` offsets in a span are relative to a `CodeMap`, but this
doesn't seem to be terribly useful for tool consumers who don't have the
codemap, but might want the byte offset within an actual file?
Auto merge of #43183 - michaelwoerister:internalize-symbols-without-llvm, r=eddyb
trans: Internalize symbols without relying on LLVM
This PR makes the compiler use the information gather by the trans collector in order to determine which symbols/trans-items can be made internal. This has the advantages:
+ of being LLVM independent,
+ of also working in incremental mode, and
+ of allowing to not keep all LLVM modules in memory at the same time.
Alex Crichton [Thu, 20 Jul 2017 18:14:13 +0000 (11:14 -0700)]
std: Cut down #[inline] annotations where not necessary
This PR cuts down on a large number of `#[inline(always)]` and `#[inline]`
annotations in libcore for various core functions. The `#[inline(always)]`
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally `#[inline]` is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.
Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to
0.7s.
Auto merge of #43281 - mmatyas:remotetest_env, r=alexcrichton
Allow remote testing remotely when `TEST_DEVICE_ADDR` is set
Remote testing was added in #41268, but at the moment it's only enabled if QEMU is also available or we're testing Android. This patch also allows remote testing if the environment variable `TEST_DEVICE_ADDR` is set, as required by `remote-test-client` [[1](https://github.com/rust-lang/rust/blob/master/src/tools/remote-test-client/src/main.rs#L28), [2](https://github.com/rust-lang/rust/blob/master/src/tools/remote-test-client/src/main.rs#L61)]
Auto merge of #43270 - petrochenkov:fixstab, r=alexcrichton
Fix checking for missing stability annotations
This was a regression from https://github.com/rust-lang/rust/pull/37676 causing "unmarked API" ICEs like https://github.com/rust-lang/rust/issues/43027.
Auto merge of #43247 - est31:master, r=alexcrichton
Tidy: allow common lang+lib features
This allows changes to the Rust language that have both library
and language components share one feature gate.
The feature gates need to be "about the same change", so that both
library and language components must either be both unstable, or
both stable, and share the tracking issue.
Removes the ugly "proc_macro" exception added by #40939.
Thomas Lively [Wed, 19 Jul 2017 17:55:12 +0000 (10:55 -0700)]
Pass debugging arguments to emcc
Tells emcc to enable assertions and debugging information for
wasm32-experimental-emscripten. This makes the codegen issues caused by
LLVM bug 33824 manifest more frequently at runtime and improves the wasm
debugging experience.
Auto merge of #43333 - Mark-Simulacrum:appveyor-fix, r=alexcrichton
Attempt to fix appveyor
This will fix the problem, I think, but I don't know that this is a good idea (potentially leaving ourselves open to attackers, I guess, if a cert was revoked...). Of course, it may not. I don't actually have windows to check on..
I'm not entirely certain if this is the best way to do it, but I figured mimicking the way it's done for PIE seemed like a good start at least. I'm not sure whether we want to have it enabled by default globally and then disabling it explicitly for targets that don't support it though. I'm also not sure whether the `full_relro` function should call `bug!()` or something like it for linkers that don't support it rather than no-opping.
Auto merge of #43168 - pnkfelix:check-attr-gating, r=aturon
Slew of builtin-attribute gating tests
Slew of builtin-attribute "gating" tests for issue #43106.
Some stray observations:
* I don't know if its a good thing that so many attributes allow inputs which are silently discarded. (I made heavy use of that in writing my tests, but that was more out of curiosity than necessity.)
* The difference between crate-level and non-crate-level behavior is quite significant in some cases. Definitely worth making sure one has tests for both cases. (Not as clear whether it was worthwhile trying the various other AST forms like `fn f()` vs `struct S;`)
* `#[no_builtins]` and `#[no_mangle]` occur twice on the `BUILTIN_ATTRIBUTES` list. Thats almost certainly a bug. (Filed as #43148)
* We are maximally liberal in what we allow for `#[test]` and `#[bench]` when one compiles without `--test`.
* We allow `#[no_mangle]` on arbitrary AST nodes, but only warn about potential misuse on `fn`
* We allow `#[cold]`, `#[must_use]`, `#[windows_subsystem]`, and `#[no_builtins]` on arbitrary AST nodes. I don't know off-hand what the semantics are for e.g. a `#[cold] type T = ...;`
* We allow crate-level `#![inline]`. That's probably a bug since its otherwise restricted to `fn` items
Auto merge of #40989 - matklad:comma-arms, r=petrochenkov
Unify rules about commas in match arms and semicolons in expressions
Original discussion: https://internals.rust-lang.org/t/syntax-of-block-like-expressions-in-match-arms/5025/7.
Currently, rust uses different rules to determine if `,` is needed after an expression in a match arm and if `;` is needed in an expression statement:
```Rust
fn stmt() {
# no need for semicolons
{ () }
if true { () } else { () }
loop {}
while true {}
}
fn match_arm(n: i32) {
match n {
1 => { () } # can omit comma here
2 => if true { () } else { () }, # but all other cases do need commas.
3 => loop { },
4 => while true {},
_ => ()
}
}
```
This seems weird: why would you want to require `,` after and `if`?
This PR unifies the rules. It is backwards compatible because it allows strictly more programs.
Mark Simulacrum [Tue, 18 Jul 2017 15:41:38 +0000 (09:41 -0600)]
Rollup merge of #43315 - est31:stabilize_float_bits_conv, r=alexcrichton
float_bits_conv made it into 1.20
It seems that my PR to stabilize the `float_bits_conv` feature got merged before beta branched, which means I'm lucky, and the stabilization makes it into Rust 1.20. As it was against my expectations, the version number has to be corrected from 1.21 to 1.20.
Mark Simulacrum [Tue, 18 Jul 2017 15:41:35 +0000 (09:41 -0600)]
Rollup merge of #43310 - lynn:rc-weak-doc-fix, r=apasel422
Fix erroneous reference to Arc instead of Rc in rc::Weak documentation
The docs for `rc::Weak` refer to `Arc` in one place, where they should obviously be referring to `Rc`; presumably this was erroneously copied over from the `arc::Weak` docs.
Mark Simulacrum [Tue, 18 Jul 2017 15:41:33 +0000 (09:41 -0600)]
Rollup merge of #43294 - insaneinside:std-time-duration-docs, r=aturon
`std::time::Duration`: improve _precision_ of terminology in docs
Changed wording of docs on `std::time::Duration` for better clarity w.r.t. the contents of the type and the purpose of its methods. (Specifically, removed the use of the word "precision" to describe the fractional part of the `Duration` because "precision" is more properly used to describe how _precise_ a value is, i.e. its granularity in this case.)
Mark Simulacrum [Tue, 18 Jul 2017 15:41:32 +0000 (09:41 -0600)]
Rollup merge of #43292 - kennytm:fix-quasi-quoting-warning-in-rustbuild, r=alexcrichton
Workaround "Quasi-quoting is inefficient" warning in incremental rustbuild introduced in #43252.
After #43252 is merged, building stage0 libcore with `-i` (`--incremental`) flag will cause 17 "Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)" warnings, as in #40946.
```
warning: Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)
--> src/libcore/default.rs:133:21
|
133 | #[doc = $doc]
| ^^^^
...
139 | default_impl! { (), (), "Returns the default value of `()`" }
| ------------------------------------------------------------- in this macro invocation
(× 17)
```
True fix for #40946 will take at least 12 weeks from now to make into the next stage0, so it is quicker to workaround it in libcore instead.
Mark Simulacrum [Tue, 18 Jul 2017 15:41:31 +0000 (09:41 -0600)]
Rollup merge of #43287 - kennytm:travis-ci-adjustments, r=alexcrichton
Change Travis CI job order.
Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`.
1. Move the `$ALLOW_PR` image to the top, so pull requests will start testing as immediately after the build is started. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled.
2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work).
3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below.
4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
(IMO `$SKIP_BUILD` should not even exist: those irrelevant jobs should not start at all, but that would require travis-ci/travis-ci#2778 which has been rejected)
Auto merge of #42492 - petrochenkov:methlife, r=nikomatsakis
Support generic lifetime arguments in method calls
Fixes https://github.com/rust-lang/rust/issues/42403
Fixes https://github.com/rust-lang/rust/issues/42115
Lifetimes in a method call `x.f::<'a, 'b, T, U>()` are treated exactly like lifetimes in the equivalent UFCS call `X::f::<'a, 'b, T, U>`.
In addition, if the method has late bound lifetime parameters (explicit or implicit), then explicitly specifying lifetime arguments is not permitted (guarded by a compatibility lint).
[breaking-change] because previously lifetimes in method calls were accepted unconditionally.
Reorder the job matrix to take advantage of the order how Travis CI starts
them in rust-lang/rust. Plus other refactoring of `.travis.yml`.
1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing
immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the
build was scheduled.
2. Move the slow macOS images near the top, so they share more time with
the rest of the faster Linux builds, which should shorten total test
time (actually not much, about 7 minutes at most if this change does
work).
3. Merged the `install` section of both Linux and macOS to make the `env:`
section a bit shorter, and enable change 4 below.
4. Do not download or install anything if `$SKIP_BUILD == true`, which
further reduces chance of spurious failure in the PR-CI stage (avoid the
red cross appearing even if CI passed).
Auto merge of #43293 - alexcrichton:fail-curl, r=Mark-Simulacrum
travis: Make a few `curl` invocations more resilient
Use the `-f` flag to indicate that, for example, a 500 response code is to be
considered a failure, triggering the normal retry logic. Also ignore errors
where we check the date from google.com, as a failure there shouldn't fail the
build.
Alex Crichton [Mon, 17 Jul 2017 17:55:27 +0000 (10:55 -0700)]
travis: Make a few `curl` invocations more resilient
Use the `-f` flag to indicate that, for example, a 500 response code is to be
considered a failure, triggering the normal retry logic. Also ignore errors
where we check the date from google.com, as a failure there shouldn't fail the
build.
Fix treatment of lifetimes defined in nested types during detection of late bound regions in signatures.
Do not replace substs with inference variables when "cannot specify lifetime arguments explicitly..." is reported as a lint.
Fix "Quasi-quoting is inefficient" warning in incremental rustbuild.
After #43252 is merged, building stage0 libcore with -i (--incremental)
flag will cause 17 "Quasi-quoting might make incremental compilation very
inefficient: NtExpr(..)" warnings, as in #40946.
Fixing the warning in #40946 will take 12 weeks from now to make into the
next stage0, so it is quicker to workaround it in libcore instead.
Auto merge of #42711 - Firstyear:san-on-dylib, r=alexcrichton
Add support for dylibs with Address Sanitizer
Many applications use address sanitizer to assert correct behaviour of their programs. When using Rust with C, it's much more important to assert correct programs with tools like asan/lsan due to the unsafe nature of the access across an ffi boundary. However, previously only rust bin types could use asan. This posed a challenge for existing C applications that link or dlopen .so when the C application is compiled with asan.
This PR enables asan to be linked to the dylib and cdylib crate type. We alter the test to check the proc-macro crate does not work with -Z sanitizer=address. Finally, we add a test that compiles a shared object in rust, then another rust program links it and demonstrates a crash through the call to the library.
This PR is nearly complete, but I do require advice on the change to fix the -lasan that currently exists in the dylib test. This is required because the link statement is not being added correctly to the rustc build when -Z sanitizer=address is added (and I'm not 100% sure why)
Oliver Schneider [Mon, 17 Jul 2017 08:16:08 +0000 (10:16 +0200)]
Move resolve diagnostic instability to compile-fail
The produced paths aren't stable between builds, since
reporting paths inside resolve, before resolve is finished
might produce paths resolved to type aliases instead of
the concrete type.
Compile-fail tests can match just parts of messages, so they
don't "suffer" from this issue.
This is just a workaround, the instability should be fixed
in the future.
Auto merge of #43258 - petrochenkov:cbabort, r=alexcrichton
Compile `compiler_builtins` with `abort` panic strategy
A workaround for https://github.com/rust-lang/rust/issues/43095
In case this causes unexpected consequences, I use a simpler workaround locally:
```diff
--- a/src/bootstrap/bin/rustc.rs
+++ b/src/bootstrap/bin/rustc.rs
@@ -175,7 +175,9 @@ fn main() {
}
if let Ok(s) = env::var("RUSTC_CODEGEN_UNITS") {
- cmd.arg("-C").arg(format!("codegen-units={}", s));
+ if crate_name != "compiler_builtins" {
+ cmd.arg("-C").arg(format!("codegen-units={}", s));
+ }
}