config.rs has reached the 3000 line tidy limit, this commit moves
command line option definitions into a new file - options.rs, and
leaves the rest of configuration infrastructure in config.rs.
adopts simple strategy devised with assistance from mw: Instead of accumulating
(and acting upon) LTO import information over an unbounded number of prior
compilations, just see if the current import set matches the previous import set.
if they don't match, then you cannot reuse the PostLTO build product for that
module.
In either case (of a match or a non-match), we can (and must) unconditionally
emit the current import set as the recorded information in the incremental
compilation cache, ready to be loaded during the next compiler run for use in
the same check described above.
resolves issue 59535.
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
After #62550, it is no longer possible for `slice`
to be other than `None | Some(Binding(..) | Wild)`.
In particular, `lower_pat_slice` may never generate
`Some(Array(..) | Slice(..))` and so there is nothing
to flatten into `slice`.
The code is dead because `check_pat_slice` will never have
`expected = ty::Ref(...)` due to default-binding-modes
(see `is_non_ref_pat`, `peel_off_references`).
Moreover, if the type is not `ty::Array(_) | ty::Slice(_)`
then `check_pat_slice` enters an error branch.
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.
