Point at `:` when using it instead of `;`
When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
Fix#42057, #41928.
Update Rust LLVM bindings for LLVM 5.0
This is the initial set of changes to update the rust llvm bindings for 5.0. The llvm commits necessitating these changes are linked from the tracking issue, #43370.
Ignore stack probe tests on AArch64
Stack probes are only implemented for x86, and as such currently fail on AArch64. This patch ignores those tests on this architecture.
Fixes#43356.
r? @alexcrichton
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
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!
```
Resolves#35164.
r? @jonathandturner
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.
This is in preparation for fixing issue #39280.
cc @rust-lang/compiler
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
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.
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.
r? @eddyb
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.
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)
Thanks,
Now there's a way to add suggestions that hide the suggested code when
presented inline, to avoid weird wording when short code snippets are
added at the end.
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.
