Set release channel on non-dist builders
Toolstate publication only runs if the channel is "nightly" and
previously the toolstate builders did not know that the channel was
nightly (since they are not dist builders).
A look through bootstrap seems to indicate that nothing should directly
depend on the channel being set to `-dev` on the test builders, though
this may cause some problems with UI tests (if for some reason they're
dumping the channel into stderr), but we cannot find evidence of such so
hopefully this is fine.
r? @pietroalbini
Add more delegations to the fmt docs and add doctests
HI,
this is a continuation to #67021
I replaced the `Debug` example with one that use the `Debug*` helpers so that padding etc will work too.
I also added asserts for the doctests as @RalfJung asked :)
The only thing I left with the `write!` macro is the `Display` example as I didn't know if there's a better way to do that.
r? @QuietMisdreavus
Rollup of 8 pull requests
Successful merges:
- #67189 (Unify binop wording)
- #67270 (std: Implement `LineWriter::write_vectored`)
- #67286 (Fix the configure.py TOML field for a couple LLVM options)
- #67321 (make htons const fn)
- #67382 (Remove some unnecessary `ATTR_*` constants.)
- #67389 (Remove `SO_NOSIGPIPE` dummy variable on platforms that don't use it.)
- #67394 (Remove outdated references to @T from comments)
- #67406 (Suggest associated type when the specified one cannot be found)
Failed merges:
r? @ghost
Suggest associated type when the specified one cannot be found
Fixes#67386, so code like this:
```
use std::ops::Deref;
fn homura<T: Deref<Trget = i32>>(_: T) {}
fn main() {}
```
results in:
```
error[E0220]: associated type `Trget` not found for `std::ops::Deref`
--> type-binding.rs:6:20
|
6 | fn homura<T: Deref<Trget = i32>>(_: T) {}
| ^^^^^^^^^^^ help: there is an associated type with a similar name: `Target`
error: aborting due to previous error
```
(The `help` is new)
I used an `all_candidates: impl Fn() -> Iterator<...>` instead of `collect`ing to avoid the cost of allocating the Vec when no errors are found, at the expense of a little added complexity.
r? @estebank
std: Implement `LineWriter::write_vectored`
This commit implements the `write_vectored` method of the `LineWriter`
type. First discovered in bytecodealliance/wasmtime#629 the
`write_vectored` method of `Stdout` bottoms out here but only ends up
writing the first buffer due to the default implementation of
`write_vectored`.
Like `BufWriter`, however, `LineWriter` can have a non-default
implementation of `write_vectored` which tries to preserve the
vectored-ness as much as possible. Namely we can have a vectored write
for everything before the newline and everything after the newline if
all the stars align well.
Also like `BufWriter`, though, special care is taken to ensure that
whenever bytes are written we're sure to signal success since that
represents a "commit" of writing bytes.
Toolstate publication only runs if the channel is "nightly" and
previously the toolstate builders did not know that the channel was
nightly (since they are not dist builders).
A look through bootstrap seems to indicate that nothing should directly
depend on the channel being set to `-dev` on the test builders, though
this may cause some problems with UI tests (if for some reason they're
dumping the channel into stderr), but we cannot find evidence of such so
hopefully this is fine.
Switch bootstrap to 1.41
This updates the version number for master to 1.42 and switches the bootstrap compiler to yesterday's beta. Fallout of cfg(bootstrap) changes is also dealt with.
Revert enabling parallelism by default
We will re-land a similar patch at a future date but for now we should get a nightly
released in a few hours with the parallel patch, so this should be
reverted to make sure that the next nightly is not parallel-enabled.
r? @ghost
This reverts commit 3ed3b8bb7b, reversing
changes made to 99b89533d4.
We will reland a similar patch at a future date but for now we should get a nightly
released in a few hours with the parallel patch, so this should be
reverted to make sure that the next nightly is not parallel-enabled.
These depend on rustc being bug-free and it looks like that's not
currently entirely the case (e.g., we know of at least one bug that
introduces nondeterminism).
This also removes the unused NO_PARALLEL_COMPILER flag; if we want that
functionality we can readd it but this makes sure we really are parallel
everywhere.
This also patches a test that has differing output in the parallel case
(hopefully deterministically so!).
This avoids the problems of high thread counts (i.e., contention in the
kernel on the jobserver pipe due to thundering herd of readers) while
stil giving rustc some parallelism to work with.
.gitignore: Don't ignore a file that exists in the repository
.gitignore should not ignore files that exist in the repository. The
ignore of .cargo applies to the committed .cargo directory used in an
example:
$ git ls-files --exclude-standard --ignored
src/test/run-make/thumb-none-qemu/example/.cargo/config
Explicitly un-ignore that file.
make transparent enums more ordinary
By recognizing that structs & unions have one variant, we can make the treatment of transparent enums less ad-hoc.
cc https://github.com/rust-lang/rust/issues/60405
r? @davidtwco
Delete flaky test net::tcp::tests::fast_rebind
This test is unreliable for at least 3 users on two platforms: see #57509 and #51006. It was added 5 years ago in #22015. Do we know whether this is testing something important that would indicate a bug in our implementation, or if it's fine to remove?
r? @sfackler @alexcrichton because this somewhat resembles #59018Closes#57509. Closes#51006.
Improve code generated for `starts_with(<literal char>)`
This PR includes two minor improvements to the code generated when checking for string prefix/suffix.
The first commit simplifies the str/str operation, by taking advantage of the raw UTF-8 representation.
The second commit replaces the current str/char matching logic with a char->str encoding and then the previous method.
The resulting code should be equivalent in the generic case (one char is being encoded versus one char being decoded), but it becomes easy to optimize in the case of a literal char, which in most cases a developer might expect to be at least as simple as that of a literal string.
This PR should fix#41993
bors