Disallow octal format in Ipv4 string
In its original specification, leading zero in Ipv4 string is interpreted
as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1.
This confusion can lead to many security vulnerabilities. Therefore, in
[IETF RFC 6943], it suggests to disallow octal/hexadecimal format in Ipv4
string all together.
Existing implementation already disallows hexadecimal numbers. This commit
makes Parser reject octal numbers.
Fixes#83648.
[IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1
Improve pointer arithmetic docs
* Add slightly more detailed definition of "allocated object" to the module docs, and link it from everywhere.
* Clarify the "remains attached" wording a bit (at least I hope this is clearer).
* Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct.
As usual, the edit needs to be done in a dozen places to remain consistent, I hope I got them all.
Clean up Vec's benchmarks
The Vec benchmarks need a lot of love. I sort of noticed this in https://github.com/rust-lang/rust/pull/83357 but the overall situation is much less awesome than I thought at the time. The first commit just removes a lot of asserts and does a touch of other cleanup.
A number of these benchmarks are poorly-named. For example, `bench_map_fast` is not in fact fast, `bench_rev_1` and `bench_rev_2` are vague, `bench_in_place_zip_iter_mut` doesn't call `zip`, `bench_in_place*` don't do anything in-place... Should I fix these, or is there tooling that depend on the names not changing?
I've also noticed that `bench_rev_1` and `bench_rev_2` are remarkably fragile. It looks like poking other code in `Vec` can cause the codegen of this benchmark to switch to a version that has almost exactly half its current throughput and I have absolutely no idea why.
Here's the fast version:
```asm
0.69 │110: movdqu -0x20(%rbx,%rdx,4),%xmm0
1.76 │ movdqu -0x10(%rbx,%rdx,4),%xmm1
0.71 │ pshufd $0x1b,%xmm1,%xmm1
0.60 │ pshufd $0x1b,%xmm0,%xmm0
3.68 │ movdqu %xmm1,-0x30(%rcx)
14.36 │ movdqu %xmm0,-0x20(%rcx)
13.88 │ movdqu -0x40(%rbx,%rdx,4),%xmm0
6.64 │ movdqu -0x30(%rbx,%rdx,4),%xmm1
0.76 │ pshufd $0x1b,%xmm1,%xmm1
0.77 │ pshufd $0x1b,%xmm0,%xmm0
1.87 │ movdqu %xmm1,-0x10(%rcx)
13.01 │ movdqu %xmm0,(%rcx)
38.81 │ add $0x40,%rcx
0.92 │ add $0xfffffffffffffff0,%rdx
1.22 │ ↑ jne 110
```
And the slow one:
```asm
0.42 │9a880: movdqa %xmm2,%xmm1
4.03 │9a884: movq -0x8(%rbx,%rsi,4),%xmm4
8.49 │9a88a: pshufd $0xe1,%xmm4,%xmm4
2.58 │9a88f: movq -0x10(%rbx,%rsi,4),%xmm5
7.02 │9a895: pshufd $0xe1,%xmm5,%xmm5
4.79 │9a89a: punpcklqdq %xmm5,%xmm4
5.77 │9a89e: movdqu %xmm4,-0x18(%rdx)
15.74 │9a8a3: movq -0x18(%rbx,%rsi,4),%xmm4
3.91 │9a8a9: pshufd $0xe1,%xmm4,%xmm4
5.04 │9a8ae: movq -0x20(%rbx,%rsi,4),%xmm5
5.29 │9a8b4: pshufd $0xe1,%xmm5,%xmm5
4.60 │9a8b9: punpcklqdq %xmm5,%xmm4
9.81 │9a8bd: movdqu %xmm4,-0x8(%rdx)
11.05 │9a8c2: paddq %xmm3,%xmm0
0.86 │9a8c6: paddq %xmm3,%xmm2
5.89 │9a8ca: add $0x20,%rdx
0.12 │9a8ce: add $0xfffffffffffffff8,%rsi
1.16 │9a8d2: add $0x2,%rdi
2.96 │9a8d6: → jne 9a880 <<alloc::vec::Vec<T,A> as core::iter::traits::collect::Extend<&T>>::extend+0xd0>
```
Don't duplicate the extern providers once for each crate
This should give a small perf improvement for small crates by avoiding a memcpy of a pretty big struct for each loaded crate. In addition would be useful for replacing the sequential `CrateNum` everywhere with the hash based `StableCrateId` introduced in #81635, which would allow avoiding remapping of `CrateNum`'s when loading crate metadata. While this PR is not strictly needed for that, it is necessary to prevent a performance loss due to it.
I think this duplication was done in https://github.com/rust-lang/rust/pull/40008 (which introduced the query system) to make it possible to compile multiple crates in a single session in the future. I think this is unlikely to be implemented any time soon. In addition this PR can easily be reverted if necessary to implement this.
When the problem for a method not being found in its receiver is due to
arbitrary self-types, we don't want to mention importing or implementing
the trait, instead we suggest wrapping.
In its original specification, leading zero in Ipv4 string is interpreted
as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1.
This confusion can lead to many security vulnerabilities. Therefore, in
[IETF RFC 6943], it suggests to disallow octal/hexadecimal format in Ipv4
string all together.
Existing implementation already disallows hexadecimal numbers. This commit
makes Parser reject octal numbers.
Fixes#83648.
[IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1
unix: Fix feature(unix_socket_ancillary_data) on macos and other BSDs
This adds support for CMSG handling on macOS and fixes it on OpenBSD and possibly other BSDs.
When traversing the CMSG list, the previous code had an exception for Android where the next element after the last pointer could point to the first pointer instead of NULL. This is actually not specific to Android: the `libc::CMSG_NXTHDR` implementation for Linux and emscripten have a special case to return NULL when the length of the previous element is zero; most other implementations simply return the previous element plus a zero offset in this case.
This MR makes the check non-optional which fixes CMSG handling and a possible endless loop on such systems; tested with file descriptor passing on OpenBSD, Linux, and macOS.
This MR additionally adds `SocketAncillary::is_empty` because clippy is right that it should be added.
This belongs to the `feature(unix_socket_ancillary_data)` tracking issue: https://github.com/rust-lang/rust/issues/76915
r? `@joshtriplett`
escape_ascii take 2
The previous PR, #73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one.
I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this.
r? ``@m-ou-se``
alloc: Added `as_slice` method to `BinaryHeap` collection
I initially asked about whether it is useful addition on https://internals.rust-lang.org/t/should-i-add-as-slice-method-to-binaryheap/13816, and it seems there were no objections, so went ahead with this PR.
> There is [`BinaryHeap::into_vec`](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.into_vec), but it consumes the value. I wonder if there is API design limitation that should be taken into account. Implementation-wise, the inner buffer is just a Vec, so it is trivial to expose as_slice from it.
Please, guide me through if I need to add tests or something else.
UPD: Tracking issue #83659
rustdoc: Don't enter an infer_ctxt in get_blanket_impls for impls that aren't blanket impls
Less broken version of https://github.com/rust-lang/rust/pull/82856.
get_blanket_impls is a *very* hot region of rustdoc, so even small changes like this should help. Unfortunately I don't have benchmarks for this until https://github.com/rust-lang/rustc-perf/pull/802 is merged.
There isn't currently a good reviewer for these, and I don't want to
remove things that will just be added again. I plan to make a separate
PR for these changes so the rest of the cleanup can land.
Riscv64linux Test fixes
Get tests passing again using the riscv64gc-unknown-linux-gnu docker image.
Test with
```
src/ci/docker/run.sh riscv64gc-linux
```
## linkcheck
Linkcheck tests that interdocument links in the documentation are correct. Some interdocument links go between rustc and tools (such as rustdoc and cargo). When cross compiling, rustc is built for the host while some tools are built for the target. This goes for the documentation too. Because of this, links in the rustc documentation reffering to cargo or rustdoc documentation look broken.
This issue is worked around by disabling linkcheck for cross compilation builds.
## run-make tests
#78911 seems to happen because `--target` was not passed to `rustc`, but the target linker was specified, causing the target linker to be called with options intended for the host.
Resolves#78911
In a separate issue, `issue-36710` was trying to run a binary built for the target on the host system. This will not work for any platform using `remote-test-server`/`client` (such as riscv64). I don't know of a way of skipping those platforms specifically, so I set this test to skip only on riscv64 for now.
Sync rustc_codegen_cranelift
The main highlight of this sync is support for cross-compiling to Windows using MinGW. Native compilation with MinGW would also work I think, but using the MSVC toolchain is not yet supported as PE TLS is not yet implemented. Another nice improvement is that crate metadata is now loaded using mmap instead of by reading files. This improves compilation time a bit.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
update Miri, and also run test suite with mir-opt-level=4
In the Miri repo, we run the Miri test suite once with default flags and once with `-O -Zmir-opt-level=4`. This helps identify and document situations where MIR optimizations mask UB -- it is okay for that to happen, but it might be god to look into it when it does happen. Recently these tests failed fairly frequently as new MIR optimizations were added, and since we only run them on the Miri side, it is not even clear which rustc PR introduced the change. So I propose we also run these tests in the rustc repo, such that toolstate tracking will tell us the exact PR (or at least the rollup) that caused the change.
r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/83590
