E0034: provide disambiguated syntax for candidates
For a given file
```rust
trait A { fn foo(&self) {} }
trait B : A { fn foo(&self) {} }
fn bar<T: B>(a: &T) {
a.foo()
}
```
provide the following output
```
error[E0034]: multiple applicable items in scope
--> file.rs:6:5
|
6 | a.foo(1)
| ^^^ multiple `foo` found
|
note: candidate #1 is defined in the trait `A`
--> file.rs:2:11
|
2 | trait A { fn foo(&self, a: usize) {} }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to use it here write `A::foo(&a, 1)` instead
--> file.rs:6:5
|
6 | a.foo(1)
| ^^^
note: candidate #2 is defined in the trait `B`
--> file.rs:3:15
|
3 | trait B : A { fn foo(&self, a: usize) {} }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to use it here write `B::foo(&a, 1)` instead
--> file.rs:6:5
|
6 | a.foo(1)
| ^^^
```
Fix#37767.
Improve the slice iterator's searching methods
Improve all, any, find, position, rposition by explicitly unrolling the loop for the slice iterators.
- Introduce a few extension methods and functions for raw pointers make the new code easy to express
- Introduce helper methods `search_while, rsearch_while` that generalize all the searching methods
LLVM doesn't unroll the loop in `.find()` by default (clang is the same), so performance benefits a lot from explicit unrolling here. An iterator method without conditional exits (like `.fold()`) does not need this on the other hand.
One of the raw pointer extension methods is `fn post_inc(&mut self) -> Self` which is the rustic equivalent of “`ptr++`”, and it is a nice way to express the raw pointer loop (see commit 3).
Specific development notes about `search_while`: I tried both computing an end pointer "rounded" to 4, as well as the `ptrdistance >= 4` loop condition, ptrdistance was better. I tried handling the last 0-3 elements unrolled or with a while loop, the loop was better.
incr.comp.: Delete orphaned work-products.
The new partitioning scheme uncovered a hole in our incr. comp. cache directory garbage collection. So far, we relied on unneeded work products being deleted during the initial cache invalidation phase. However, we the new scheme, we get object files/work products that only contain code from upstream crates. Sometimes this code is not needed anymore (because all callers have been removed from the source) but because nothing that actually influences the contents of these work products had changed, we never deleted them from disk.
r? @nikomatsakis
All our releases are compiled with this, so let's be sure to do so whenever
`DEPLOY` is set. This'll ensure that we don't have dynamic dependencies on
libstdc++ which LLVM depends on, but instead we link it all statically to have
more portable binaries.
Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring
`ObjectSum` and `PolyTraitRef` are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them.
The first commit replaces `Path` with `Ty` in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality.
The third commit uses `Vec` instead of `P<[T]>` in AST. AST is not immutable like HIR and `Vec`s are more convenient for it, unnecessary conversions are also avoided.
The last commit renames `parse_ty_sum` (which is used for parsing types in general) into `parse_ty`, and renames `parse_ty` (which is used restricted contexts where `+` is not permitted due to operator priorities or other reasons) into `parse_ty_no_plus`.
This is the first part of https://github.com/rust-lang/rust/issues/39085#issuecomment-272743755 and https://github.com/rust-lang/rust/issues/39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.
r? @eddyb
travis: Pass --release-channel=nightly on deploy
This commit passes the `--release-channel=nightly` flag to all images which have
the `DEPLOY` flag set. This means that we'll name artifacts and the compiler
appropriately.
This reworks a bit how arguments are passed, but for now doesn't change what's
already being passed. Eventually we'll want to avoid enabling debug assertions
and llvm assertions for *all* releases, but I figure we can tackle that a little
bit more down the road.
* Add support for `#[proc_macro]`
* Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it
* Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`,
error on legacy import of proc macros via `#[macro_use]`
This commit passes the `--release-channel=nightly` flag to all images which have
the `DEPLOY` flag set. This means that we'll name artifacts and the compiler
appropriately.
This reworks a bit how arguments are passed, but for now doesn't change what's
already being passed. Eventually we'll want to avoid enabling debug assertions
and llvm assertions for *all* releases, but I figure we can tackle that a little
bit more down the road.
This expands the `cross` travis matrix entry with a few more targets that our
nightlies are building:
* x86_64-rumprun-netbsd
* arm-unknown-linux-musleabi
* arm-unknown-linux-musleabihf
* armv7-unknown-linux-musleabihf
* mips-unknown-linux-musl
* mipsel-unknown-linux-musl
This commit doesn't compile custom toolchains like our current cross-image does,
but instead compiles musl manually and then compiles libunwind manually (like
x86_64) for use for the ARM targets and just uses openwrt toolchains for the
mips targets.
This is a target that we're shipping today, so this commit adds this matrix
entry to AppVeyor. This reuses the existing i686 MSVC matrix entry as it's
currently finishing about a half hour under two hours, which should hopefully
give it enough extra time to run this test suite.
