Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 7 pull requests #104187

Closed
wants to merge 25 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Lukas Markeffsky and others added 25 commits October 26, 2022 11:58
These have been bugging me for a while.

- `literal_text`: `src` is also used and is shorter and better.
- `first_char`: used even when "first" doesn't make sense; `c` is
  shorter and better.
- `curr`: `c` is shorter and better.
- `unescaped_char`: `result` is also used and is shorter and better.
- `second_char`: these have a single use and can be elided.
There is some subtlety here.
It's passed to numerous places where we just need an `is_byte` bool.
Passing the bool avoids the need for some assertions.

Also rename `is_bytes()` as `is_byte()`, to better match `Mode::Byte`,
`Mode::ByteStr`, and `Mode::RawByteStr`.
There are three kinds of "byte" literals: byte literals, byte string
literals, and raw byte string literals. None are allowed to have
non-ASCII chars in them.

Two `EscapeError` variants exist for when that constraint is violated.
- `NonAsciiCharInByte`: used for byte literals and byte string literals.
- `NonAsciiCharInByteString`: used for raw byte string literals.

As a result, the messages for raw byte string literals use different
wording, without good reason. Also, byte string literals are incorrectly
described as "byte constants" in some error messages.

This commit eliminates `NonAsciiCharInByteString` so the three cases are
handled similarly, and described correctly. The `mode` is enough to
distinguish them.

Note: Some existing error messages mention "byte constants" and some
mention "byte literals". I went with the latter here, because it's a
more correct name, as used by the Reference.
Remove a low-value comment, remove a duplicate comment, and correct a
third comment.
It deals with eight cases: ints, floats, and the six quoted types
(char/byte/strings). For ints and floats we have an early return, and
the other six types fall through to the code at the end, which makes the
function hard to read.

This commit rearranges things to avoid the early returns.
It has a single callsite, and is fairly small. The `Float` match arm
already has base-specific checking inline, so this makes things more
consistent.
It's easy to just use `unescape_literal` + `byte_from_char`.
The `usize` isn't needed in the error case.
Stabilize integer logarithms

Stabilizes feature `int_log`.

I've also made the functions const stable, because they don't depend on any unstable const features. `rustc_allow_const_fn_unstable` is just there for `Option::expect`, which could be replaced with a `match` and `panic!`. cc `@rust-lang/wg-const-eval`

closes rust-lang#70887 (tracking issue)

~~blocked on FCP finishing: rust-lang#70887 (comment)
FCP finished: rust-lang#70887 (comment)
…cottmcm

Add documentation examples for `pointer::mask`

The examples are somewhat convoluted, but I don't know how to make this better :(
…=matklad

Unescaping cleanups

Some code improvements, and some error message improvements.

Best reviewed one commit at a time.

r? ```@matklad```
…ce, r=Mark-Simulacrum

Don't intra linkcheck reference

This removes the reference from the intra-doc link checks. This causes problems if any of the reference content needs to change, it causes the linkchecker to break. The reference has its own broken link check (https://github.com/rust-lang/reference/tree/master/style-check) which uses pulldown-cmark on the source to find actual broken links (instead of false-positives like this regex does).

I think the intra-doc link check could potentially be removed completely, since I think rustdoc is now checking for them well enough. However, it may serve as a decent regression check.
…, r=thomcc

Add test for impl of `available_parallelism()`

This checks that `std::thread::available_parallelism()` returns `Ok(NonZeroUsize)`. With this test maintainers of targets(OS) can check if they have implemented this function (or decide to ignore it).

Not sure how to deal with the ignore list right now:

- tier 1's should all implement the feature already ✔️
- tier 2's mostly do as well, but not e.g. `ios`, `wasi` -- should we add them to the ignore list or let the maintainers do that (so that they are informed)?
- tier 3's will certainly sometimes not implement it, my suggestion is to not add them to the ignore list
- I've added only `vxworks`, `redox` and `l4re` to the ignore list because this is documented already in `library/std/src/sys/unix/thread.rs` ([code](https://github.com/rust-lang/rust/blob/9b735a7132acd58b3bd34c084e9ca5b4ca7450a2/library/std/src/sys/unix/thread.rs#L403))

We could also check the value against e.g. `cat /proc/cpuinfo | grep process or | wc`  but I don't know if this is required (how much sense it makes) and if this would play well with e.g. cgroups on Linux.

r? `@thomcc`
…scription-for-as-simd-mut, r=scottmcm

rustdoc: Add mutable to the description

Add mutable the description to differentiate [as_simd](https://github.com/rust-lang/rust/blob/master/library/core/src/slice/mod.rs#L3654) from [as_simd_mut](https://github.com/rust-lang/rust/blob/master/library/core/src/slice/mod.rs#L3654).
…r=fee1-dead

Const Compare for Tuples

Makes the impls for Tuples of ~const `PartialEq` types also `PartialEq`, impls for Tuples of ~const `PartialOrd` types also `PartialOrd`, for Tuples of ~const `Ord` types also `Ord`.

behind the `#![feature(const_cmp)]` gate.

~~Do not merge before rust-lang#104113 is merged because I want to use this feature to clean up the new test that I added there.~~

r? `@fee1-dead`
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Nov 9, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Nov 9, 2022

📌 Commit f89a485 has been approved by Dylan-DPC

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 9, 2022
@bors
Copy link
Contributor

bors commented Nov 9, 2022

⌛ Testing commit f89a485 with merge 8e8c5968583ae28e7f8bb9d912a3f8b35ef5f84d...

@bors
Copy link
Contributor

bors commented Nov 9, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 9, 2022
@Dylan-DPC Dylan-DPC closed this Nov 9, 2022
@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [ui] src/test/ui/transmutability/primitives/numbers.rs ... ok

failures:

---- [ui] src/test/ui/thread-available_parallelism.rs stdout ----
error: test run failed!
status: exit status: 101
status: exit status: 101
command: "/node-v15.14.0-linux-x64/bin/node" "/checkout/src/etc/wasm32-shim.js" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/thread-available_parallelism/a.wasm"
stdout: none
--- stderr -------------------------------
RuntimeError: unreachable
    at __rust_start_panic (<anonymous>:wasm-function[74]:0x4cc8)
    at rust_panic (<anonymous>:wasm-function[71]:0x4c8e)
    at _ZN3std9panicking20rust_panic_with_hook17hc73a70925786882dE (<anonymous>:wasm-function[70]:0x4c5e)
    at _ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h7f5f3ae987f1af25E (<anonymous>:wasm-function[60]:0x435b)
    at _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h185a02d230e881b2E (<anonymous>:wasm-function[59]:0x4288)
    at rust_begin_unwind (<anonymous>:wasm-function[65]:0x48b2)
    at _ZN4core9panicking9panic_fmt17h1e2bb86f52aeefd3E (<anonymous>:wasm-function[120]:0x55f0)
    at _ZN4core6result13unwrap_failed17hc4e20a91daf996c2E (<anonymous>:wasm-function[145]:0x66db)
    at _ZN28thread_available_parallelism4main17h03326d289402e501E (<anonymous>:wasm-function[5]:0x335)
    at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hf58fe416dcfc238fE (<anonymous>:wasm-function[0]:0x1ef)
    at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h908b31335600f762E (<anonymous>:wasm-function[1]:0x211)
    at _ZN3std2rt19lang_start_internal17h8a5b5e510fe566d4E (<anonymous>:wasm-function[48]:0x38e8)
    at main (<anonymous>:wasm-function[6]:0x36e)
    at Object.<anonymous> (/checkout/src/etc/wasm32-shim.js:20:20)
    at Module._compile (node:internal/modules/cjs/loader:1092:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1121:10)
    at Module.load (node:internal/modules/cjs/loader:972:32)
    at Function.Module._load (node:internal/modules/cjs/loader:813:14)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12)
    at node:internal/main/run_main_module:17:47



failures:

@Dylan-DPC Dylan-DPC deleted the rollup-jh3fjij branch November 11, 2022 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants