Since these elements now use `white-space: pre-wrap` since
784665d4ce, it's fine to use newlines
for formatting, which is smaller and a bit less complicated.
Rollup of 8 pull requests
Successful merges:
- #100599 (Add compiler error E0523 long description and test)
- #107471 (rustdoc: do not include empty default-settings tag in HTML)
- #107555 (Modify existing bounds if they exist)
- #107662 (Turn projections into copies in CopyProp.)
- #107695 (Add test for Future inflating arg size to 3x )
- #107700 (Run the tools builder on all PRs)
- #107706 (Mark 'atomic_mut_ptr' methods const)
- #107709 (Fix problem noticed in PR106859 with char -> u8 suggestion)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
llvm-16: Use Triple.h from new header location.
LLVM 16 has moved Triple.h from ADT and into TargetParser.
LLVM [landed a commit](62c7f035b4) this morning moving the header. This change should make rustc continue to build against LLVM main.
Fix problem noticed in PR106859 with char -> u8 suggestion
HN reader `@ayosec` noticed that my #106859 a few weeks back, malfunctions if you have a Unicode escape, the code suggested b'\u{0}' if you tried to use '\u{0}' where a byte should be, when of course b'\u{0}' is not a byte literal, regardless of the codepoint you can't write Unicode escapes in a byte literal at all.
My proposed fix here just checks that the "character" you wrote is fewer than 5 bytes, thus allowing \x7F and similar escapes but conveniently forbidding even the smallest Unicode escape \u{0} before offering the suggestion as before.
I have provided an updated test which includes examples which do and don't work because of this additional rule.
Mark 'atomic_mut_ptr' methods const
There's nothing that would block these methods from being const (just an UnsafeCell get), and it would be helpful for FFI interfaces in static contexts
Related tracking issue: #66893
Run the tools builder on all PRs
Previously, it would only run on changes to subtrees, submodules, or select directories. That made it so that changes to the compiler that broke tools would only be detected on a full bors merge. This makes it so the tools builder runs by default, making it easier to catch breaking changes to clippy (which was the most affected).
r? ``@Mark-Simulacrum`` cc ``@pietroalbini`` ``@flip1995`` ``@m-ou-se``
Split fn_ctxt/adjust_fulfillment_errors from fn_ctxt/checks
This is a follow-up from #106477, addressing a small number of the `FIXME`s that were added, by moving some functions into the new(er) `adjust_fulfillment_errors` module.
More cleanup is possible for this file (and I'll hopefully get around to doing some of that soon) but the very first thing is to just move these functions out.
There should be no "real" changes in this PR, besides minor adjustments to imports and the functions being transferred.
Turn projections into copies in CopyProp.
The current implementation can leave behind projections that are moved out several times.
This PR widens the check to turn such moves into copies: a move out of a projection of a copy is equivalent to a copy of the original projection.
Modify existing bounds if they exist
Fixes#107335.
This implementation is kinda gross but I don't really see a better way to do it.
This primarily does two things: Modifies `suggest_constraining_type_param` to accept a new parameter that indicates a span to be replaced instead of added, if presented, and limit the additive suggestions to either suggest a new bound on an existing bound (see newly added unit test) or add the generics argument if a generics argument wasn't found.
The former change is required to retain the capability to add an entirely new bounds if it was entirely omitted.
r? ``@compiler-errors``
Fix suggestions rendering when the diff span is multiline
Fixes#92741
cc `@estebank`
I think, I finally fixed. I still want to go back and try to clean up the code a bit. I'm open to suggestions.
Some examples of the new suggestions:
```
help: consider removing the borrow
|
2 - &
|
```
```
help: consider removing the borrow
|
2 - &
3 - mut
|
```
```
help: consider removing the borrow
|
2 - &
3 - mut if true { true } else { false }
2 + if true { true } else { false }
|
```
Should we add a test to ensure this behavior doesn't disappear in the future?
Run `expand-yaml-anchors` in `x test tidy`
Previously, the pre-commit hook which runs `x test tidy` could pass only to have CI fail within the first 30 seconds. This adds about 30 seconds to `test tidy` (for an initial run, much less after the tool is built the first time) in exchange for catching errors in `.github/workflows/ci.yml` before they're pushed.
This adds one more test that should track improvements to generator
layout, like #62958 and #62575.
In particular, this test highlights suboptimal layout, as the storage
for the argument future is not being reused across its usage as `upvar`,
`local` and `awaitee` (being polled to completion).
make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias
See https://github.com/rust-lang/unsafe-code-guidelines/issues/381 and [this LLVM discussion](https://discourse.llvm.org/t/interaction-of-noalias-and-dereferenceable/66979). The exact semantics of how `noalias` and `dereferenceable` interact are unclear, and `@comex` found a case of LLVM actually exploiting that ambiguity for optimizations. I think for now we should treat LLVM `dereferenceable` as implying a "fake read" to happen immediately at the top of the function (standing in for the spurious reads that LLVM might introduce), and that fake read is subject to all the usual `noalias` restrictions. This means we cannot put `dereferenceable` on `&mut !Unpin` references as those references can alias with other references that are being read and written inside the function (e.g. for self-referential generators), meaning the fake read introduces aliasing conflicts with those other accesses.
For `&` this is already not a problem due to https://github.com/rust-lang/rust/pull/98017 which removed the `dereferenceable` attribute for other reasons.
Regular `&mut Unpin` references are unaffected, so I hope the impact of this is going to be tiny.
The first commit does some refactoring of the `PointerKind` enum since I found the old code very confusing each time I had to touch it. It doesn't change behavior.
Fixes https://github.com/rust-lang/miri/issues/2714
EDIT: Turns out our `Box<!Unpin>` treatment was incorrect, too, so the PR also fixes that now (in codegen and Miri): we do not put `noalias` on these boxes any more.
Rollup of 9 pull requests
Successful merges:
- #106477 (Refine error spans for "The trait bound `T: Trait` is not satisfied" when passing literal structs/tuples)
- #107596 (Add nicer output to PGO build timer)
- #107692 (Sort Generator `print-type-sizes` according to their yield points)
- #107714 (Clarify wording on f64::round() and f32::round())
- #107720 (end entry paragraph with a period (.))
- #107724 (remove unused rustc_* imports)
- #107725 (Turn MarkdownWithToc into a struct with named fields)
- #107731 (interpret: move discriminant reading and writing to separate file)
- #107735 (Add mailmap for commits made by xes@meta.com)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: move discriminant reading and writing to separate file
This is quite different from the otherwise fairly general read and write functions in place.rs and operand.rs, and also it's nice to have these two functions close together as they are basically inverses of each other.
Clarify wording on f64::round() and f32::round()
"Round half-way cases" is a little confusing (it's a 'garden path sentence' as it's not immediately clear whether round is an adjective or verb).
Make this sentence longer and clearer.
Sort Generator `print-type-sizes` according to their yield points
Especially when trying to diagnose runaway future sizes, it might be more intuitive to sort the variants according to the control flow (aka their yield points) rather than the size of the variants.
Add nicer output to PGO build timer
This PR modifies the timer used in the PGO build script to contain nicer, hierarchical output of the individual build steps. It's not trivial to test locally, so I'll fire up a dist build right away.
r? ``@Mark-Simulacrum``
