This change weakens the descriptions of the
`{as,into,from}_raw_{fd,handle,socket}` descriptions from saying that
they *do* express ownership relations to say that they are *typically used*
in ways that express ownership relations. This needed needed since, for
example, std's own [`RawFd`] implements `{As,From,Into}Fd` without any of
the ownership relationships.
This adds proper `# Safety` comments to `from_raw_{fd,handle,socket}`,
adds the requirement that raw handles be not opened with the
`FILE_FLAG_OVERLAPPED` flag, and merges the `OwnedHandle::from_raw_handle`
comment into the main `FromRawHandle::from_raw_handle` comment.
And, this changes `HandleOrNull` and `HandleOrInvalid` to not implement
`FromRawHandle`, since they are intended for limited use in FFI situations,
and not for generic use, and they have constraints that are stronger than
the those of `FromRawHandle`.
[`RawFd`]: https://doc.rust-lang.org/stable/std/os/unix/io/type.RawFd.html
Implement `RawWaker` and `Waker` getters for underlying pointers
implement #87021
New APIs:
- `RawWaker::data(&self) -> *const ()`
- `RawWaker::vtable(&self) -> &'static RawWakerVTable`
- ~`Waker::as_raw_waker(&self) -> &RawWaker`~ `Waker::as_raw(&self) -> &RawWaker`
This third one is an auxiliary function to make the two APIs above more useful. Since we can only get `&Waker` in `Future::poll`, without this, we need to `transmute` it into `&RawWaker` (relying on `repr(transparent)`) in order to access its data/vtable pointers.
~Not sure if it should be named `as_raw` or `as_raw_waker`. Seems we always use `as_<something-raw>` instead of just `as_raw`. But `as_raw_waker` seems not quite consistent with `Waker::from_raw`.~ As suggested in https://github.com/rust-lang/rust/pull/91828#discussion_r770729837, use `as_raw`.
Enable combining `+crt-static` and `relocation-model=pic` on `x86_64-unknown-linux-gnu`
Modern `gcc` versions support `-static-pie`, and `rustc` will already fall-back to `-static` if the local `gcc` is too old (and hence this change is optimistic rather than absolute). This brings the `-musl` and `-gnu` targets to feature compatibility (albeit with different default settings).
Of note a `-static` or `-static-pie` binary based on glibc that uses NSS-backed functions (`gethostbyname` or `getpwuid` etc.) need to have access to the `libnss_X.so.2` libraries and any of their dynamic dependencies.
I wasn't sure about the `# only`/`# ignore` changes (I've not got a `gnux32` toolchain to test with hence not also enabling `-static-pie` there).
Disable drop range analysis
The previous PR, #93165, still performed the drop range analysis despite ignoring the results. Unfortunately, there were ICEs in the analysis as well, so some packages failed to build (see the issue #93197 for an example). This change further disables the analysis and just provides dummy results in that case.
Carefully remove bounds checks from some chunk iterator functions
So, I was writing code that requires the equivalent of `rchunks(N).rev()` (which isn't the same as forward `chunks(N)` — in particular, if the buffer length is not a multiple of `N`, I must handle the "remainder" first).
I happened to look at the codegen output of the function (I was actually interested in whether or not a nested loop was being unrolled — it was), and noticed that in the outer `rchunks(n).rev()` loop, LLVM seemed to be unable to remove the bounds checks from the iteration: https://rust.godbolt.org/z/Tnz4MYY8f (this panic was from the split_at in `RChunks::next_back`).
After doing some experimentation, it seems all of the `next_back` in the non-exact chunk iterators have the issue: (`Chunks::next_back`, `RChunks::next_back`, `ChunksMut::next_back`, and `RChunksMut::next_back`)...
Even worse, the forward `rchunks` iterators sometimes have the issue as well (... but only sometimes). For example https://rust.godbolt.org/z/oGhbqv53r has bounds checks, but if I uncomment the loop body, it manages to remove the check (which is bizarre, since I'd expect the opposite...). I suspect it's highly dependent on the surrounding code, so I decided to remove the bounds checks from them anyway. Overall, this change includes:
- All `next_back` functions on the non-`Exact` iterators (e.g. `R?Chunks(Mut)?`).
- All `next` functions on the non-exact rchunks iterators (e.g. `RChunks(Mut)?`).
I wasn't able to catch any of the other chunk iterators failing to remove the bounds checks (I checked iterations over `r?chunks(_exact)?(_mut)?` with constant chunk sizes under `-O3`, `-Os`, and `-Oz`), which makes sense, since these were the cases where it was harder to prove the bounds check correct to remove...
In fact, it took quite a bit of thinking to convince myself that using unchecked_ here was valid — so I'm not really surprised that LLVM had trouble (although compilers are slightly better at this sort of reasoning than humans). A consequence of that is the fact that the `// SAFETY` comment for these are... kinda long...
---
I didn't do this for, or even think about it for, any of the other iteration methods; just `next` and `next_back` (where it mattered). If this PR is accepted, I'll file a follow up for someone (possibly me) to look at the others later (in particular, `nth`/`nth_back` looked like they had similar logic), but I wanted to do this now, as IMO `next`/`next_back` are the most important here, since they're what gets used by the iteration protocol.
---
Note: While I don't expect this to impact performance directly, the panic is a side effect, which would otherwise not exist in these loops. That is, this could prevent the compiler from being able to move/remove/otherwise rework a loop over these iterators (as an example, it could not delete the code for a loop whose body computes a value which doesn't get used).
Also, some like to be able to have confidence this code has no panicking branches in the optimized code, and "no bounds checks" is kinda part of the selling point of Rust's iterators anyway.
Rollup of 9 pull requests
Successful merges:
- #91343 (Fix suggestion to slice if scrutinee is a `Result` or `Option`)
- #93019 (If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase)
- #93090 (`impl Display for io::ErrorKind`)
- #93456 (Remove an unnecessary transmute from opaque::Encoder)
- #93492 (Hide failed command unless in verbose mode)
- #93504 (kmc-solid: Increase the default stack size)
- #93513 (Allow any pretty printed line to have at least 60 chars)
- #93532 (Update books)
- #93533 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
10 commits in 1c034752de0df744fcd7788fcbca158830b8bf85..25fcb135d02ea897ce894b67ae021f48107d522b
2022-01-25 22:36:53 +0000 to 2022-02-01 01:32:48 +0000
- fix(install): Keep v1 file formatting the same (rust-lang/cargo#10349)
- fix(vendor): Use tables for sample config (rust-lang/cargo#10348)
- Add bash completion for `cargo clippy` (rust-lang/cargo#10347)
- Do not ignore `--features` when `--all-features` is present (rust-lang/cargo#10337)
- test: Fix compatibilty with new toml_edit (rust-lang/cargo#10350)
- extra-link-arg-etc: support all link types (credit `@davidhewitt)` (rust-lang/cargo#10274)
- Make clippy happy (rust-lang/cargo#10340)
- Update publishing link for semver rules. (rust-lang/cargo#10338)
- Normalize --path when install bin outside current workspace (rust-lang/cargo#10335)
- Bump clap to v3.0.13 (rust-lang/cargo#10336)
Update books
## nomicon
4 commits in 66d097d3d80e8f88c288c6879c7c2b909ecf8ad4..9493715a6280a1f74be759c7e1ef9999b5d13e6f
2022-01-05 05:45:21 +0900 to 2022-01-27 19:00:32 -0800
- send-and-sync: it's -> its (rust-lang/nomicon#332)
- Clarify the HRTB chapter (rust-lang/nomicon#330)
- Clarify repr(transparent) in other-reprs (rust-lang/nomicon#329)
- Make C code more recognizably C (rust-lang/nomicon#331)
## reference
10 commits in 4dee6eb63d728ffb9e7a2ed443e9ada9275c69d2..411c2f0d5cebf48453ae2d136ad0c5e611d39aec
2022-01-18 09:26:33 -0800 to 2022-01-30 12:46:37 -0800
- paths.md: update comments of `Canoical paths` section (rust-lang/reference#1146)
- Add undocumented outer attributes above StructExpr fields (rust-lang/reference#1150)
- (rust-lang/reference#1148)
- Fix micro typo in async/unsafe function docs (rust-lang/reference#1145)
- Note difference in CTFE timing between associated and free constants (rust-lang/reference#1120)
- Update the Preludes chapter for the 2021 edition changes to the standard library prelude (rust-lang/reference#1136)
- Link to associated constants section rather than glossary (rust-lang/reference#1141)
- functions.md: replace `argument` with `parameter` (rust-lang/reference#1142)
- Improve rendering (rust-lang/reference#1143)
- (minor) link references and replace wording by syntax definition (rust-lang/reference#1139)
## book
24 commits in f17df27fc14696912c48b8b7a7a8fa49e648088d..98904efaa4fc968db8ff59cf2744d9f7ed158166
2022-01-18 17:46:28 -0500 to 2022-01-29 21:22:31 -0500
- Snapshot of chapter 17 for nostarch
- Remove the section on object safety.
- Don't put a hyphen in 'object safe'. Fixesrust-lang/book#2960.
- Clarify that add_text on Post will work in any state. Fixesrust-lang/book#2159.
- Fix incorrect descriptions of what the code is doing. Fixesrust-lang/book#2745.
- Fix link style and inclusion in print
- Snapshot of ch16 for nostarch
- Cut discussion of threading models Rust *doesn't* support.
- Update a quote of compiler output
- Move transfers between threads, not shares. Fixesrust-lang/book#2843.
- Ch20-02 Remove reference to a long-gone "trick"
- Clarify translations a bit
- Added a mention to the translations appendix
- Fix listing number from `8-5` to `9-5` in `ch09-02`
- Moving example into blockquote means it can't be extracted to a listing project
- Move a link to the end with all the other links
- Propagate edits back to ch 9
- Responding to edits in chapter 9
- Update to 1.58
- Snapshot of chapter 15 for nostarch
- Change 'only difference' to 'main difference'. Fixesrust-lang/book#1581.
- Add a back reference to tuple struct syntax. Fixesrust-lang/book#1916
- Add a link to a section reference
- Remove an outdated example that says it won't compile but it does
## rustc-dev-guide
2 commits in 78dd6a4684cf8d6b72275fab6d0429ea40b66338..8763adb62c712df69b1d39ea3e692b6d696cc4d9
2022-01-18 14:44:26 -0300 to 2022-01-26 14:01:40 -0800
- git.md: Expanded a note to try to stress what you need to do if you're playing
- Clarify that r? works in comments.
## embedded-book
1 commits in 8c395bdd8073deb20ca67e1ed4b14a3a7e315a37..d5fc1bce3f8eb398f9c25f1b15e0257d7537cd41
2021-11-14 11:38:31 +0000 to 2022-01-24 07:13:31 +0000
- Add link to Japanese translation (rust-embedded/book#311)
Allow any pretty printed line to have at least 60 chars
Follow-up to #93155. The rustc AST pretty printer has a tendency to get stuck in "vertical smear mode" when formatting highly nested code, where it puts a linebreak at *every possible* linebreak opportunity once the indentation goes beyond the pretty printer's target line width:
```rust
...
((&([("test"
as
&str)]
as
[&str; 1])
as
&[&str; 1]),
(&([]
as
[ArgumentV1; 0])
as
&[ArgumentV1; 0]))
...
```
```rust
...
[(1
as
i32),
(2
as
i32),
(3
as
i32)]
as
[i32; 3]
...
```
This is less common after #93155 because that PR greatly reduced the total amount of indentation, but the "vertical smear mode" failure mode is still just as present when you have deeply nested modules, functions, or trait impls, such as in the case of macro-expanded code from `-Zunpretty=expanded`.
Vertical smear mode is never the best way to format highly indented code though. It does not prevent the target line width from being exceeded, and it produces output that is less readable than just a longer line.
This PR makes the pretty printing algorithm allow a minimum of 60 chars on every line independent of indentation. So as code gets more indented, the right margin eventually recedes to make room for formatting without vertical smear.
```console
├─────────────────────────────────────┤
├─────────────────────────────────────┤
├─────────────────────────────────────┤
├───────────────────────────────────┤
├─────────────────────────────────┤
├───────────────────────────────┤
├─────────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├─────────────────────────────┤
├───────────────────────────────┤
├─────────────────────────────────┤
├───────────────────────────────────┤
├─────────────────────────────────────┤
```
kmc-solid: Increase the default stack size
This PR increases the default minimum stack size on the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets to 64KiB (Arm) and 128KiB (AArch64).
This value was chosen as a middle ground between supporting a relatively complex program (e.g., an application using a full-fledged off-the-shelf web server framework) with no additional configuration and minimizing resource consumption for the embedded platform that doesn't support lazily-allocated pages nor over-commitment (i.e., wasted stack spaces are wasted physical memory). If the need arises, the users can always set the `RUST_MIN_STACK` environmental variable to override the default stack size or use the platform API directly.
Hide failed command unless in verbose mode
This is particularly intended for invoking compiletest; the command line there
is long (3,350 characters on my system) and takes up a lot of screen real estate
for little benefit to the majority of those running bootstrap. This moves
printing it to verbose mode (-v must be passed) which means that it's still
possible to access when needed for debugging.
The main downside is that CI logs will by-default become less usable for
debugging (particularly) spurious failures, but it is pretty rare for us to
really need the information there -- it's usually fairly obvious what is being
run with a little investigation.
r? `@ehuss` as you've done some of the spurious failure investigations, so can
(hopefully) confirm my intuition that this won't seriously hinder them.
If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase
The current error for this case isn't really great, it just complains about the whole thing past the `0` being an invalid suffix.
rustc_errors: only box the `diagnostic` field in `DiagnosticBuilder`.
I happened to need to do the first change (replacing `allow_suggestions` with equivalent functionality on `Diagnostic` itself) as part of a larger change, and noticed that there's only two fields left in `DiagnosticBuilderInner`.
So with this PR, instead of a single pointer, `DiagnosticBuilder` is two pointers, which should work just as well for passing *it* by value (and may even work better wrt some operations, though probably not by much).
But anything that was already taking advantage of `DiagnosticBuilder` being a single pointer, and wrapping it further (e.g. `Result<T, DiagnosticBuilder>` w/ non-ZST `T`), ~~will probably see a slowdown~~, so I want to do a perf run before even trying to propose this.
Check that `#[rustc_must_implement_one_of]` is applied to a trait
`#[rustc_must_implement_one_of]` only makes sense when applied to a trait, so it's sensible to emit an error otherwise.
Store def_id_to_hir_id as variant in hir_owner.
If hir_owner is Owner(_), the LocalDefId is pointing to an owner, so the ItemLocalId is 0.
If the HIR node does not exist, we store Phantom.
Otherwise, we store the HirId associated to the LocalDefId.
Related to #89278
r? `@oli-obk`
