The "unit value" is a value of the "unit type," not the "unit value type." Regardless of correctness, this straight syntax is easier to grok.
Part of #16676
Sorry if something's off here, it's my first pull request to rust!
Unlike coercing from reference to unsafe pointer, coercing between two
unsafe pointers doesn't need an AutoDerefRef, because there is no region
that regionck would need to know about.
In unoptimized libcore, this reduces the number of "auto_deref" allocas
from 174 to 4.
It would skip the middle part if it was 0, displaying a number a 1000
times too small. The MB/s number next to it gave it away.
Fixed it looks like this:
```
test h ... bench: 1,000,129 ns/iter (+/- 4,730)
```
Because these structures are created by a macro, the doc comments
don't quite work: the leading /// isn't stripped. Instead, just
use #[doc] so that they render correctly.
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
r? @steveklabnik
again, do it once and then just remember the expanded form. At the same
time, filter globally nameable predicates out of the environment, since
they can cause cache errors (and they are not necessary in any case).
that are known to have been satisfied *somewhere*. This means that if
one fn finds that `SomeType: Foo`, then every other fn can just consider
that to hold.
Unfortunately, there are some complications:
1. If `SomeType: Foo` includes dependent conditions, those conditions
may trigger an error. This error will be repored in the first fn
where `SomeType: Foo` is evaluated, but not in the other fns, which
can lead to uneven error reporting (which is sometimes confusing).
2. This kind of caching can be unsound in the presence of
unsatisfiable where clauses. For example, suppose that the first fn
has a where-clause like `i32: Bar<u32>`, which in fact does not
hold. This will "fool" trait resolution into thinking that `i32:
Bar<u32>` holds. This is ok currently, because it means that the
first fn can never be calle (since its where clauses cannot be
satisfied), but if the first fn's successful resolution is cached, it
can allow other fns to compile that should not. This problem is fixed
in the next commit.
In https://github.com/rust-lang/rust/pull/23289, I did not include the type information for searching for orphan methods (methods that are defined in a module and implemented in another - doing this causes rustdoc sometimes to first find the impl before the actual type).
This PR fixes this. By merging this, searches for `char -> bool` will also find `is_alphabetic`, for example (which otherwise was only found for `charext -> bool`).
cc @alexcrichton
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
Because these structures are created by a macro, the doc comments
don't quite work: the leading /// isn't stripped. Instead, just
use #[doc] so that they render correctly.
musl may not be available on the target user's machine, and even if it is, we may not be able to find it because of how static libraries are searched for.
Instead, use the liblibc archive created at rust compile time which already contains libc.a.
---
To be honest, my brain is bending a bit at this point and I wonder if I'm doing something a bit stupid.
Problem: building the libc crate with target musl. It says "could not find native static library `c`, perhaps an -L flag is missing?".
Some pondering: the key problem is the way static archives are searched for (note that a musl build attempts to statically link to libc) - they aren't. There are three locations which are checked (including `$PREFIX/lib/rustlib/x86_64-unknown-linux-musl/lib`), but this does not include `$PREFIX/lib`...and it probably shouldn't - rustc is mimicking the way native lib generation works by forcing you to provide the path yourself. You can make it work `cargo rustc` with `-L native=/path/to/musl/lib`, but even if this went in a build script for the libc crate, it wouldn't work if musl isn't installed by the end user.
I've sprinkled `not(test)` around but I've no idea if I've done it right.
This patch allows `cargo build --target x86_64-unknown-linux-musl` to work on a crate with a dependency on libc, where the musl-enabled rust was compiled before this patch. I've not yet kicked off the long process to build a musl-enabled rust with this patch, so it might be broken there.
Sorry for the rambling.
r? @alexcrichton
musl may not be available on the target user's machine, and even if
it is, we may not be able to find it because of how static libraries
are searched for.
Instead, use the transitively included liblibc which includes libc.a.
Closes#25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
[breaking-change]
As it says in the title. I've added an `expect` method to `Result` that allows printing both an error message (e.g. what operation was attempted), and the error value. This is separate from the `unwrap` and `ok().expect("message")` behaviours.
Closes#25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
[breaking-change]
The plugin that enforces error explanation line-length is a bit restrictive, particularly when attempting to use URLs in explanations (cf #26163).
Jashank will still have to do some mucking around with `#[cfg(not(stage0))]` attributes or else wait until a snapshot with this commit lands.
don't try to bind __morestack symbol under OpenBSD as the platform don't
have morestack support.
r? @alexcrichton
it unbreak build under OpenBSD. Does some others platforms don't have morestack too ? They should be impacted by this problem too.
`assert_eq!` has better diagnostics than `assert!` and is more helpful when something actually breaks, but the diagnostics has it's price - `assert_eq!` generate some formatting code which is slower to compile and possibly run.
[My measurements](https://internals.rust-lang.org/t/assert-a-b-or-assert-eq-a-b/1367/12?u=petrochenkov) show that presence of this formatting code doesn't affect compilation + execution time of the test suite significantly, so `assert_eq!` can be used instead of `assert!` consistently.
(Some tests doesn't reside in src/test, they are not affected by these changes, I'll probably open a separate PR for them later)
