this resolves type-variables early in assemble_candidates and
bails out quickly if the self type is an inference variable (which would
fail anyway because of `assemble_candidates_from_projected_tys`).
In both these cases, `assemble_candidates_from_impls` would try to go
over all impls and match them, leading to O(`n*m`) performance. Fixing this
improves rustc type-checking performance by 10%. As type-checking is only
is 5% of compilation, this doesn't impact bootstrap times, but *does*
improve type-error-detection time which is nice.
Crates that have many dependencies and contain significant amounts of
generic functions could see a bigger perf boost. As a microbenchmark,
the crate generated by
```
echo '#![feature(rustc_private)]'
echo 'extern crate rustc_driver;'
for i in {1..1000}; do cat << _EOF_
pub fn foo$i<T>() {
let mut v = Vec::new();
let _w = v.clone();
v.push("");
}
_EOF_
done
```
sees performance improve from 7.2 to 1.4 seconds. I imagine many crates
would fall somewhere in-between.
r? @nikomatsakis
Nothing too big, a few needless returns and a few closures eliminated (the latter may improve performance in some cases, at least compilation should be a bit faster).
And replace more `0 as *const T`/`0 as *mut T`s with `null()`/`null_mut()`s
I'm not sure what is the general policy about making simple functions `const`, but `null()` and `null_mut()` seem to be good candidates.
Originally in an example it reads as follows:
```rust
fn inverse<T>() -> T
// this is using ConvertTo as if it were "ConvertFrom<i32>"
where i32: ConvertTo<T> {
42.convert()
}
```
There was no mention of `ConvertFrom` elsewhere in the page other than in this comment. Is this supposed to be `ConvertTo<i64>` ?
I'm confused by this example.
r? @steveklabnik
##### About the `struct` section specifically:
I wasn't sure how you'd feel about the first instance since it was originally capitalized, happy to change it back if you think that's better.
Also, I left 'tuple struct' as is since together it isn't a keyword. The first instance currently has single quotes but the others have nothing. I think that feels right.
##### Generally:
I'm working through the book now and I'm happy to keep updating this branch with any formatting tweaks or updates I find if that's easier for you guys, otherwise I'll just create smaller PRs as I go. Just let me know.
Because 'doc' is a directory, when running `make doc`, you'll see
this:
make: Nothing to be done for `doc'.
By adding a target for `doc` to build `docs`, both work.
Fixes#14705
Because 'doc' is a directory, when running `make doc`, you'll see
this:
make: Nothing to be done for `doc'.
By adding a target for `doc` to build `docs`, both work.
Fixes#14705
r? @nikomatsakis
Trying to land this first stab, which basically just duplicates the AST. Will file issues for the various things I've got in mind to improve.
this resolves type-variables early in assemble_candidates and
bails out quickly if the self type is an inference variable (which would
fail anyway because of `assemble_candidates_from_projected_tys`).
In both these cases, `assemble_candidates_from_impls` would try to go
over all impls and match them, leading to O(n*m) performance. Fixing this
improves rustc type-checking performance by 10%. As type-checking is only
is 5% of compilation, this doesn't impact bootstrap times, but *does*
improve type-error-detection time which is nice.
Crates that have many dependencies and contain significant amounts of
generic functions could see a bigger perf boost. As a microbenchmark,
the crate generated by
echo '#![feature(rustc_private)]'
echo 'extern crate rustc_driver;'
for i in {1..1000}; do cat << _EOF_
pub fn foo$i<T>() {
let mut v = Vec::new();
let _w = v.clone();
v.push("");
}
_EOF_
done
sees performance improve from 7.2 to 1.4 seconds. I imagine many crates
would fall somewhere in-between.
