syntax: Simplify parsing of paths
Discern between `Path` and `Path<>` in AST (but not in HIR).
Give span to angle bracketed generic arguments (`::<'a, T>` in `path::segment::<'a, T>`).
This is a refactoring in preparation for https://internals.rust-lang.org/t/macro-path-uses-novel-syntax/5561/3, but it doesn't add anything to the grammar yet.
r? @jseyfried
Extended error message for mut borrow conflicts in loops
RFC issue: https://github.com/rust-lang/rfcs/issues/2080
The error message for multiple mutable borrows on the same value over loop iterations now makes it clear that the conflict comes from the borrow outlasting the loop. The wording of the error is based on the special case of the moved-value error for a value moved in a loop. Following the example of that error, the code remains the same for the special case.
This is mainly because I felt the current message is confusing in the loop case : https://github.com/rust-lang/rust/issues/43437. It's not clear that the two conflicting borrows are in different iterations of the loop, and instead it just looks like the compiler has an issue with a single line.
Stabilize more APIs for the 1.20.0 release
In addition to the few stabilizations that have already landed, this cleans up the remaining APIs that are in `final-comment-period` right now to be stable by the 1.20.0 release
Point at path segment on module not found
Point at the correct path segment on a import statement where a module
doesn't exist.
New output:
```rust
error[E0432]: unresolved import `std::bar`
--> <anon>:1:10
|
1 | use std::bar::{foo1, foo2};
| ^^^ Could not find `bar` in `std`
```
instead of:
```rust
error[E0432]: unresolved import `std::bar::foo1`
--> <anon>:1:16
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
error[E0432]: unresolved import `std::bar::foo2`
--> <anon>:1:22
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
```
Fix#43040.
Make the "main" constructors of NonZero/Shared/Unique return Option
Per discussion in https://github.com/rust-lang/rust/issues/27730#issuecomment-303939441.
This is a breaking change to unstable APIs.
The old behavior is still available under the name `new_unchecked`. Note that only that one can be `const fn`, since `if` is currently not allowed in constant contexts.
In the case of `NonZero` this requires adding a new `is_zero` method to the `Zeroable` trait. I mildly dislike this, but it’s not much worse than having a `Zeroable` trait in the first place. `Zeroable` and `NonZero` are both unstable, this can be reworked later.
Point at the correct path segment on a import statement where a module
doesn't exist.
New output:
```rust
error[E0432]: unresolved import `std::bar`
--> <anon>:1:10
|
1 | use std::bar::{foo1, foo2};
| ^^^ Could not find `bar` in `std`
```
instead of:
```rust
error[E0432]: unresolved import `std::bar::foo1`
--> <anon>:1:16
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
error[E0432]: unresolved import `std::bar::foo2`
--> <anon>:1:22
|
1 | use std::bar::{foo1, foo2};
| ^^^^ Could not find `bar` in `std`
```
Add a disabled builder for aarch64 emulated tests
This commit adds a disabled builder which will run all tests for the standard
library for aarch64 in a QEMU instance. Once we get enough capacity to run this
on Travis this can be used to boost our platform coverage of AArch64
This commit adds a disabled builder which will run all tests for the standard
library for aarch64 in a QEMU instance. Once we get enough capacity to run this
on Travis this can be used to boost our platform coverage of AArch64
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
