Extend io::copy buffer reuse to BufReader too
previously it was only able to use BufWriter. This was due to a limitation in the BufReader generics that prevented specialization. This change works around the issue by using `BufReader where Self: Read` instead of `BufReader<I> where I: Read`. This limits our options, e.g. we can't access the inner reader, but it happens to work out if we rely on some implementation details.
Copying 1MiB from `/dev/zero` to `/dev/null` through a 256KiB BufReader yields following improvements
```
OLD:
io::copy::tests::bench_copy_buf_reader 51.44µs/iter +/- 703.00ns
NEW:
io::copy::tests::bench_copy_buf_reader 18.55µs/iter +/- 237.00ns
```
Previously this would read 256KiB into the reader but then copy 8KiB chunks to the writer through an additional intermediate buffer inside `io::copy`. Since those devices don't do much work most of the speedup should come from fewer syscalls and avoided memcopies.
The b3sum crate [notes that the default buffer size in io::copy is too small](4108923f52/b3sum/src/main.rs (L235-L239)). With this optimization they could achieve the desired performance by wrapping the reader in a `BufReader` instead of handrolling it.
Currently the optimization doesn't apply to things like `StdinLock`, but this can be addressed with an additional `AsMutBufReader` specialization trait.
previously it was only able to use BufWriter. This was due to a limitation in the
BufReader generics that prevented specialization. This change works around the issue
by using `where Self: Read` instead of `where I: Read`. This limits our options, e.g.
we can't access BufRead methods, but it happens to work out if we rely on some
implementation details.
Simplify `ImplSource` candidates a bit
Reduce the number of impl source candidates, which will hopefully make our life easier when trying to adapt things like `SelectionContext::select` and `codegen_select_candidate` for the new solver.
r? `@lcnr` but feel free to reassign
Add `AliasKind::Weak` for type aliases.
`type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a
```rust
trait Identity {
type Identity;
}
impl<T: Debug> Identity for T {
type Identity = T;
}
<NotDebug as Identity>::Identity
```
type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer.
Similarly:
* a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes
* rustdoc expands the type alias, even though often times users use them for documentation purposes
* diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about.
For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident.
To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition.
Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds.
As a side effect, easily allows fixing https://github.com/rust-lang/rust/issues/108617, which I did.
fixes https://github.com/rust-lang/rust/issues/108617
There's no need for the `const_eval_select` dance here. And while I originally wrote the `.try_into().unwrap_unchecked()` implementation here, it's kinda a mess in MIR -- this new one is substantially simpler, as shown by the old one being above the inlining threshold but the new one being below it.
Along with replacing fvdl uses with the equivalent ffx commands, this
also switches from using the install path for libstd-*.so and
libtest-*.so to using the build directory (now passed on the command
line). The user no longer needs to run x.py install before running tests
now, and the correct libstd and libtest are detected on run instead of
startup so the test runner can handle recompilations after starting the
testing environment.
Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`
We just use an if-let to match on an optional clause at all the places where we transition from `Predicate` -> `Clause`, but I assume that when things like item-bounds and param-env start to only store `Clause`s then those can just be trivially dropped.
r? ``@lcnr``
`#[lang_item]` for `core::ptr::Unique`
Tree Borrows is about to introduce experimental special handling of `core::ptr::Unique` in Miri to give it a semantics.
As of now there does not seem to be a clean way (i.e. other than `&format!("{adt:?}") == "std::ptr::Unique"`) to check if an `AdtDef` represents a `Unique`.
r? `@RalfJung`
Draft: making a lang item
Ignore the always part of #[inline(always)] in MIR inlining
`#[inline(always)]` is used in two cases: for functions that are so trivial it is always profitable to inline them, but also for functions which LLVM thinks are a bad inlining candidate, but which actually turn out to be profitable to inline. That second justification doesn't apply to the MIR inliner, so ignoring our cost estimation for these functions is not necessarily the right right thing to do.
This is basically a wash on non-check runs and a perf benefit in check runs. There are some notable regressions, and I think we might be able to claw those back by turning `#[inline(always)]` into a stronger hint. But I think this PR stands decently on its own as a tidy simplification.
rustdoc: Add search result item types after their name
Here what it looks like:
![Screenshot from 2023-04-22 15-16-58](https://user-images.githubusercontent.com/3050060/233789566-b5f3f625-3b78-4c56-a7ee-0a4f2d62e667.png)
The idea is to improve accessibility by providing this information directly in the text and not only in the text color. Currently we already use it for doc aliases and for primitive types, so I extended it to all types.
r? `@notriddle`