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 15 pull requests #90118

Closed
wants to merge 133 commits into from
Closed

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

syvb and others added 30 commits July 8, 2021 14:13
The way octal literals are written in IP addresses differs from the way
they are written in Rust code, so the way that octal/hex literals in IPs
are written is explictly mentioned.
Now that there can't be a bunch of leading zeros, parsing can be
optimized a bit.
* dirs-sys v0.3.4 -> v0.3.6 to drop a lot of deps
regex v1.3.1 -> v1.4.3 drops thread_local 0.3.6
bytecount v0.6.0 -> v0.6.2 replaces packed_simd with packed_simd_2
ignore v0.4.11 -> v0.4.17 drop crossbeam-channel v0.4.0

* itertools 8.0 -> 9.0
bump `ignore` version in Cargo.toml

* cargo_metadata 0.8 -> 0.12

* env_logger 0.6 -> 0.8
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
Co-authored-by: Cheng XU <3105373+xu-cheng@users.noreply.github.com>
This is possible now that rustdoc allows passing
`--document-private-items` more than once.
…mulacrum

Document private items for rustfmt

This is possible now that rust-lang#73936 has been merged.
A demonstration of the fix is included in the PR associated with this
commit.
Separates out search and direct linking, uses header ids for direct linking and `?search=term` for filtering configurations.
Once the app mounts the page is scrolled to the current header set in the url hash.
* Adds query param for version no

This adds support for using a query parameter for selecting the version no

* Adds error handling to configuration request

Catch request exception in case fetching the configuration from the url fails, this can happen either if non existent version number is passed in or because of server issues.

* Makes version selection better

Covers a few common cases in which the version number can be specified.
- Preserve search and version parameter updates in the url
- Render headings with an anchor to itself for easier linking to config
  options, variants, etc.

Demo: https://5efeb81ca3f0d.htmlsave.net/
CleanCut and others added 17 commits October 20, 2021 14:19
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Reject octal zeros in IPv4 addresses

This fixes rust-lang#86964 by rejecting octal zeros in IP addresses, such that `192.168.00.00000000` is rejected with a parse error, since having leading zeros in front of another zero indicates it is a zero written in octal notation, which is not allowed in the strict mode specified by RFC 6943 3.1.1. Octal rejection was implemented in rust-lang#83652, but due to the way it was implemented octal zeros were still allowed.
Remove unnecessary condition in Barrier::wait()

This is my first pull request for Rust, so feel free to call me out if anything is amiss.

After some examination, I realized that the second condition of the "spurious-wakeup-handler" loop in ``std::sync::Barrier::wait()`` should always evaluate to ``true``, making it redundant in the ``&&`` expression.

Here is the affected function before the fix:
```rust
#[stable(feature = "rust1", since = "1.0.0")]
pub fn wait(&self) -> BarrierWaitResult {
    let mut lock = self.lock.lock().unwrap();
    let local_gen = lock.generation_id;
    lock.count += 1;
    if lock.count < self.num_threads {
        // We need a while loop to guard against spurious wakeups.
        // https://en.wikipedia.org/wiki/Spurious_wakeup
        while local_gen == lock.generation_id && lock.count < self.num_threads { // fixme
            lock = self.cvar.wait(lock).unwrap();
        }
        BarrierWaitResult(false)
    } else {
        lock.count = 0;
        lock.generation_id = lock.generation_id.wrapping_add(1);
        self.cvar.notify_all();
        BarrierWaitResult(true)
    }
}
```

At first glance, it seems that the check that ``lock.count < self.num_threads`` would be necessary in order for a thread A to detect when another thread B has caused the barrier to reach its thread count, making thread B the "leader".

However, the control flow implicitly results in an invariant that makes observing ``!(lock.count < self.num_threads)``, i.e. ``lock.count >= self.num_threads`` impossible from thread A.

When thread B, which will be the leader, calls ``.wait()`` on this shared instance of the ``Barrier``, it locks the mutex in the first line and saves the ``MutexGuard`` in the ``lock`` variable. It then increments the value of ``lock.count``. However, it then proceeds to check if ``lock.count < self.num_threads``. Since it is the leader, it is the case that (after the increment of ``lock.count``), the lock count is *equal* to the number of threads. Thus, the second branch is immediately taken and ``lock.count`` is zeroed. Additionally, the generation ID is incremented (with wrap). Then, the condition variable is signalled. But, the other threads are waiting at the line ``lock = self.cvar.wait(lock).unwrap();``, so they cannot resume until thread B's call to ``Barrier::wait()`` returns, which drops the ``MutexGuard`` acquired in the first ``let`` statement and unlocks the mutex.

The order of events is thus:
1. A thread A calls `.wait()`
2. `.wait()` acquires the mutex, increments `lock.count`, and takes the first branch
3. Thread A enters the ``while`` loop since the generation ID has not changed and the count is less than the number of threads for the ``Barrier``
3. Spurious wakeups occur, but both conditions hold, so the thread A waits on the condition variable
4. This process repeats for N - 2 additional times for non-leader threads A'
5. *Meanwhile*, Thread B calls ``Barrier::wait()`` on the same barrier that threads A, A', A'', etc. are waiting on. The thread count reaches the number of threads for the ``Barrier``, so all threads should now proceed, with B being the leader. B acquires the mutex and increments the value ``lock.count`` only to find that it is not less than ``self.num_threads``. Thus, it immediately clamps ``self.num_threads`` back down to 0 and increments the generation. Then, it signals the condvar to tell the A (prime) threads that they may continue.
6. The A, A', A''... threads wake up and attempt to re-acquire the ``lock`` as per the internal operation of a condition variable. When each A has exclusive access to the mutex, it finds that ``lock.generation_id`` no longer matches ``local_generation`` **and the ``&&`` expression short-circuits -- and even if it were to evaluate it, ``self.count`` is definitely less than ``self.num_threads`` because it has been reset to ``0`` by thread B *before* B dropped its ``MutexGuard``**.

Therefore, it my understanding that it would be impossible for the non-leader threads to ever see the second boolean expression evaluate to anything other than ``true``. This PR simply removes that condition.

Any input would be appreciated. Sorry if this is terribly verbose. I'm new to the Rust community and concurrency can be hard to explain in words. Thanks!
`AbstractConst` private fields

Calls `subst` in `AbstractConst::root` when `Node` is `Leaf`.

r? `@lcnr`
…_with_nul, r=JohnTitor

Stabilize CString::from_vec_with_nul[_unchecked]

Closes the tracking issue rust-lang#73179. I am keeping this in _draft_ mode until the FCP has ended.

This is my first time stabilizing a feature, so I would appreciate any guidance on things I should do differently.

Closes rust-lang#73179
…in_overflow, r=m-ou-se

Avoid overflow in `VecDeque::with_capacity_in()`.

The overflow only happens if alloc is compiled with overflow checks enabled and the passed capacity is greater or equal 2^(usize::BITS-1). The overflow shadows the expected "capacity overflow" panic leading to a test failure if overflow checks are enabled for std in the CI.

Unblocks [CI: Enable overflow checks for test (non-dist) builds rust-lang#89776](rust-lang#89776).

For some reason the overflow is only observable with optimization turned off, but that is a separate issue.
…t, r=Mark-Simulacrum

Add test for debug logging during incremental compilation

Debug logging during incremental compilation had been broken for some
time, until rust-lang#89343 fixed it (among other things). Add a test so this is
less likely to break without being noticed. This test is nearly a copy
of the `src/test/ui/rustc-rust-log.rs` test, but tests debug logging in
the incremental compliation code paths.
…mulacrum

config: add the option to enable LLVM tests

I'm working on some LLVM patches in concert with a Rust patch, and it's
helping me quite a bit to have this as an option. It doesn't seem that
hard, so I figured I'd formalize it in x.py and send it upstream.
… r=jsha

Add test for line-number setting

The first commit updates the version of the package to be able to have multi-line commands (which looks much nicer for this test).

r? ```@jsha```
Remove hir::map::blocks and use FnKind instead

The principal tool is `FnLikeNode`, which is not often used and can be easily implemented using `rustc_hir::intravisit::FnKind`.
2229 migrations small cleanup

This removes needless `format!`'ing of empty string and replaces `vec!` with const strings with const array.
Make `From` impls of NonZero integer const.

I also changed the feature gate added to `From` impls of Atomic integer to `const_num_from_num` from `const_convert`.

Tracking issue: rust-lang#87852
…calebcartwright

Sync rustfmt subtree

There's a large number of small fixes and new features, but nothing too big. Detailed changelog for those interested can be found in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#1438-2021-10-20
…ntry-reexported-macro, r=notriddle

Add test for duplicated sidebar entries for reexported macro

Fixes rust-lang#90015.

r? ```@notriddle```
…l-missing-doc-code-examples, r=jyn514

Add test to ensure that the missing_doc_code_examples is not triggered on foreign trait implementations

Fixes rust-lang#76450.

r? ```@jyn514```
…olnay

Fix MIRI UB in `Vec::swap_remove`

Fixes rust-lang#90055

I find it weird that `Vec::swap_remove` read the last element to the stack just to immediately put it back in the `Vec` in place of the one at index `index`. It seems much more natural to me to just read the element at position `index` and then move the last element in its place. I guess this might also slightly improve codegen.
@rustbot rustbot added the rollup A PR which is a rollup label Oct 21, 2021
@JohnTitor
Copy link
Member Author

@bors r+ p=15 rollup=never

@bors
Copy link
Contributor

bors commented Oct 21, 2021

📌 Commit 0cb360d has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 21, 2021
@bors
Copy link
Contributor

bors commented Oct 21, 2021

⌛ Testing commit 0cb360d with merge 31c1e78d3937581bfb4046d1d4e3a6f8333d1c5a...

@bors
Copy link
Contributor

bors commented Oct 21, 2021

💔 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 Oct 21, 2021
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    Checking cargo_metadata v0.14.0
[RUSTC-TIMING] rustc_workspace_hack test:false 0.031
[RUSTC-TIMING] cargo_metadata test:false 1.526
 Documenting rustfmt-nightly v1.4.38 (/checkout/src/tools/rustfmt)
error: this URL is not a hyperlink
    |
406 |     /// See https://doc.rust-lang.org/rustdoc/print.html#attributes
406 |     /// See https://doc.rust-lang.org/rustdoc/print.html#attributes
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://doc.rust-lang.org/rustdoc/print.html#attributes>`
    |
    = note: `-D rustdoc::bare-urls` implied by `-D warnings`
    = note: bare URLs are not automatically turned into clickable links
error: could not document `rustfmt-nightly`

Caused by:
Caused by:
  process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustdoc --edition=2021 --crate-type lib --crate-name rustfmt_nightly src/tools/rustfmt/src/lib.rs --target aarch64-unknown-linux-gnu -o /checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/doc --cfg 'feature="cargo-fmt"' --cfg 'feature="default"' --cfg 'feature="rustfmt-format-diff"' --error-format=json --json=diagnostic-rendered-ansi -L dependency=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps --extern annotate_snippets=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libannotate_snippets-0895509c92d2c37e.rmeta --extern anyhow=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libanyhow-320d24e018a2a58d.rmeta --extern bytecount=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libbytecount-c9da3444e422f5ba.rmeta --extern cargo_metadata=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libcargo_metadata-daaa8d21b25f2f5c.rmeta --extern derive_new=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps/libderive_new-fde4c217dc65237d.so --extern diff=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libdiff-0a0216b342f4505d.rmeta --extern dirs=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libdirs-38c74536caad710a.rmeta --extern env_logger=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libenv_logger-a7e6b7875e4c8cce.rmeta --extern getopts=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libgetopts-424e8bf9abec9a08.rmeta --extern ignore=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libignore-66a55281edf4f6e7.rmeta --extern itertools=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libitertools-e5cf5047fee63d6c.rmeta --extern lazy_static=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/liblazy_static-5531ccc1275eea69.rmeta --extern log=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/liblog-77af63f356250e8a.rmeta --extern regex=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libregex-eb57b9492b1b9be7.rmeta --extern rustc_workspace_hack=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/librustc_workspace_hack-6ba80e98f127e157.rmeta --extern rustfmt_config_proc_macro=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps/librustfmt_config_proc_macro-be1246634532f99b.so --extern serde=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libserde-1e690c8eae6ddaa2.rmeta --extern serde_json=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libserde_json-509904f0a526d710.rmeta --extern structopt=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libstructopt-dd11797ffc9c4dda.rmeta --extern term=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libterm-376aeb560e7004e4.rmeta --extern thiserror=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libthiserror-9f592bc6fd543e92.rmeta --extern toml=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libtoml-9536e3b4a66f5f14.rmeta --extern unicode_segmentation=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libunicode_segmentation-6f0131b5d55f3f29.rmeta --extern unicode_width=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libunicode_width-21f92fab996c7120.rmeta --extern unicode_categories=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/deps/libunicode_categories-c677b36b1efd2cfd.rmeta -Dwarnings '-Wrustdoc::invalid_codeblock_attributes' --crate-version '1.58.0-nightly
  (31c1e78d3
  2021-10-21)' --document-private-items --enable-index-page --show-type-layout --generate-link-to-definition -Zunstable-options` (exit status: 1)
[RUSTC-TIMING] rustfmt_nightly test:false 7.645
error: build failed



command did not execute successfully: "/checkout/obj/build/aarch64-unknown-linux-gnu/stage0/bin/cargo" "doc" "--target" "aarch64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "14" "--release" "--locked" "--color" "always" "--manifest-path" "/checkout/src/tools/rustfmt/Cargo.toml" "--features" "rustc-workspace-hack/all-static" "-Zskip-rustdoc-fingerprint" "--no-deps" "-p" "rustfmt-nightly" "-p" "rustfmt-config_proc_macro"


Build completed unsuccessfully in 0:38:08

@JohnTitor JohnTitor closed this Oct 21, 2021
@JohnTitor JohnTitor deleted the rollup-3btewlq branch October 21, 2021 05:10
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.