After the socket ancillary data implementation was introduced, the
build was broken on FreeBSD, add the same workaround as for the
existing implementations.
Remove ExtendElement, ExtendWith, extend_with
Related to #104624, broken up into two commits. The first removes wrapper trait ExtendWith and its only implementer struct ExtendElement. The second may have perf issues so may be reverted/removed if no alternate fix is found; it should be profiled.
r? `@scottmcm`
- Switch TypeId to 128 bits
- Hack around the fact that tracing-subscriber dislikes how TypeId is hashed
- Remove lowering of type_id128 from rustc_codegen_llvm
- Remove unnecessary `type_id128` intrinsic (just change return type of `type_id`)
- Only hash the lower 64 bits of the TypeId
- Reword comment
add `#[doc(alias="flatmap")]` to `Option::and_then`
I keep forgetting that rust calls this `and_then` and trying to search for `flatmap`. `and_then`'s docs even mention "Some languages call this operation flatmap", but it doesn't show up as a result in the search at `https://doc.rust-lang.org/std/?search=flatmap`
Option::map_or_else: Show an example of integrating with Result
Moving this from https://github.com/rust-lang/libs-team/issues/59 where an API addition was rejected. But I think it's valuable to add this example to the documentation at least.
QNX Neutrino: exponential backoff when fork/spawn needs a retry
Fixes#108594: When retrying, sleep with an exponential duration. When sleep duration is lower than minimum possible sleeping time, yield instead (this will not be often due to the exponential increase of duration).
Minimum possible sleeping time is determined using `libc::clock_getres` but only when spawn/fork failed the first time in a request. This is cached using a LazyLock.
CC `@gh-tr`
r? `@workingjubilee`
`@rustbot` label +O-neutrino
use c literals in compiler and library
Use c literals #108801 in compiler and library
currently blocked on:
* <strike>rustfmt: don't know how to format c literals</strike> nope, nightly one works.
* <strike>bootstrap</strike>
r? `@ghost`
`@rustbot` blocked
Require that const param tys implement `ConstParamTy`
1. Require that const param tys implement `ConstParamTy` instead of using `search_for_adt_const_param_violation`
2. Add `StructuralPartialEq` as a supertrait for `ConstParamTy`, since we need to make sure that we derive *both* `PartialEq` and `Eq`
3. Implement `ConstParamTy` for tuples up to 12 (or whatever the default for tuples is)
4. Add some custom diagnostics to `ConstParamTy` errors, to avoid regressions from (1.). It's still not as great as it could be -- will point out inline in comments.
r? `@BoxyUwU`
Fix bug in utf16_to_utf8 for zero length strings
This fixes the behavior of sending EOF by pressing Ctrl+Z => Enter in a windows console.
Previously, that would trip the unpaired surrogate error, whereas now we correctly detect EOF.
remove reference to Into in ? operator core/std docs, fix#111655
remove the text stating that `?` uses `Into::into` and add text stating it uses `From::from` instead. This closes#111655.
Uplift `clippy::cast_ref_to_mut` lint
This PR aims at uplifting the `clippy::cast_ref_to_mut` lint into rustc.
## `cast_ref_to_mut`
(deny-by-default)
The `cast_ref_to_mut` lint checks for casts of `&T` to `&mut T` without using interior mutability.
### Example
```rust,compile_fail
fn x(r: &i32) {
unsafe {
*(r as *const i32 as *mut i32) += 1;
}
}
```
### Explanation
Casting `&T` to `&mut T` without interior mutability is undefined behavior, as it's a violation of Rust reference aliasing requirements.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::cast_ref_to_mut` into rustc
This fixes the behavior of sending EOF by pressing Ctrl+Z => Enter in a
windows console.
Previously, that would trip the unpaired surrogate error, whereas now we
correctly detect EOF.
Update cargo
17 commits in 64fb38c97ac4d3a327fc9032c862dd28c8833b17..f7b95e31642e09c2b6eabb18ed75007dda6677a0
2023-05-23 18:53:23 +0000 to 2023-05-30 19:25:02 +0000
- chore: detect the channel a PR wants to merge into (rust-lang/cargo#12181)
- refactor: de-depulicate `make_dep_prefix` implementation (rust-lang/cargo#12203)
- Re-enable code_generation test on Windows (rust-lang/cargo#12199)
- docs: add doc comments for git source and friends (rust-lang/cargo#12192)
- test: set retry sleep to 1ms for all tests (rust-lang/cargo#12194)
- fix(add): Reduce the chance we re-format the user's `[features]` table (rust-lang/cargo#12191)
- test(add): Remove expensive test (rust-lang/cargo#12188)
- Add a description of `Cargo.lock` conflicts in the Cargo FAQ (rust-lang/cargo#12185)
- refactor(tests): Reduce cargo-add setup load (rust-lang/cargo#12189)
- Warn when an edition 2021 crate is in a virtual workspace with default resolver (rust-lang/cargo#10910)
- refactor(tests): Reduce cargo-remove setup load (rust-lang/cargo#12184)
- chore: Lexicographically order `-Z` flags (rust-lang/cargo#12182)
- chore(ci): remove temporary fix for rustup 1.24.1 (rust-lang/cargo#12180)
- fix: AIX searches dynamic libraries in `LIBPATH`. (rust-lang/cargo#11968)
- deps: remove unused features from windows-sys (rust-lang/cargo#12176)
- Automatically inherit workspace lints when running cargo new/init (rust-lang/cargo#12174)
- Test that the new `debuginfo` options match between cargo and rustc (rust-lang/cargo#12022)
r? `@ghost`
Allow limited access to `OsStr` bytes
`OsStr` has historically kept its implementation details private out of
concern for locking us into a specific encoding on Windows.
This is an alternative to rust-lang#95290 which proposed specifying the encoding on Windows. Instead, this
only specifies that for cross-platform code, `OsStr`'s encoding is a superset of UTF-8 and defines
rules for safely interacting with it
At minimum, this can greatly simplify the `os_str_bytes` crate and every
arg parser that interacts with `OsStr` directly (which is most of those
that support invalid UTF-8).
Tracking issue: #111544
Uplift `clippy::invalid_utf8_in_unchecked` lint
This PR aims at uplifting the `clippy::invalid_utf8_in_unchecked` lint into two lints.
## `invalid_from_utf8_unchecked`
(deny-by-default)
The `invalid_from_utf8_unchecked` lint checks for calls to `std::str::from_utf8_unchecked` and `std::str::from_utf8_unchecked_mut` with an invalid UTF-8 literal.
### Example
```rust
unsafe {
std::str::from_utf8_unchecked(b"cl\x82ippy");
}
```
### Explanation
Creating such a `str` would result in undefined behavior as per documentation for `std::str::from_utf8_unchecked` and `std::str::from_utf8_unchecked_mut`.
## `invalid_from_utf8`
(warn-by-default)
The `invalid_from_utf8` lint checks for calls to `std::str::from_utf8` and `std::str::from_utf8_mut` with an invalid UTF-8 literal.
### Example
```rust
std::str::from_utf8(b"ru\x82st");
```
### Explanation
Trying to create such a `str` would always return an error as per documentation for `std::str::from_utf8` and `std::str::from_utf8_mut`.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
````@rustbot```` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::invalid_utf8_in_unchecked` into rustc
`[T; N]::zip` is "eager" but most zips are mapped.
This causes poor optimization in generated code.
This is a fundamental design issue and "zip" is
"prime real estate" in terms of function names,
so let's free it up again.
All the implementations of the trait already are `Copy`, and this seems to be enough to simplify the implementations enough to make the MIR inliner willing to inline basics like `Range::next`.
