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 #92216

Merged
merged 15 commits into from
Dec 23, 2021
Merged

Rollup of 7 pull requests #92216

merged 15 commits into from
Dec 23, 2021

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Michael Spector and others added 15 commits September 11, 2021 18:40
This follows the Closure Compiler dialect of JSDoc, so we
can use it to do some basic type checking. We don't plan to
compile with Closure Compiler, just use it to check types. See
https://github.com/google/closure-compiler/wiki/ for details.
Allow reverse iteration of lowercase'd/uppercase'd chars

The PR implements `DoubleEndedIterator` trait for `ToLowercase` and `ToUppercase`.

This enables reverse iteration of lowercase/uppercase variants of character sequences.
One of use cases:  determining whether a char sequence is a suffix of another one.

Example:

```rust
fn endswith_ignore_case(s1: &str, s2: &str) -> bool {
    for eob in s1
        .chars()
        .flat_map(|c| c.to_lowercase())
        .rev()
        .zip_longest(s2.chars().flat_map(|c| c.to_lowercase()).rev())
    {
        match eob {
            EitherOrBoth::Both(c1, c2) => {
                if c1 != c2 {
                    return false;
                }
            }
            EitherOrBoth::Left(_) => return true,
            EitherOrBoth::Right(_) => return false,
        }
    }
    true
}
```
Fix duplicate derive clone suggestion

closes rust-lang#91492

The addition of:
```rust
derives.sort();
derives.dedup();
```
is what actually solves the problem.
The rest is just cleanup.

I want to improve the diagnostic message to provide the suggestion as a proper diff but ran into some problems, so I'll attempt that again in a follow up PR.
Add some JSDoc comments to rustdoc JS

This follows the Closure Compiler dialect of JSDoc, so we can use it to do some basic type checking. We don't plan to compile with Closure Compiler, just use it to check types. See https://github.com/google/closure-compiler/wiki/ for details.

To try checking the annotations, run:

```
npm i -g google-closure-compiler
google-closure-compiler -W VERBOSE build/x86_64-unknown-linux-gnu/doc/{search-index1.59.0.js,crates1.59.0.js} src/librustdoc/html/static/js/{search.js,main.js,storage.js} --externs src/librustdoc/html/static/js/externs.js >/dev/null
```

You'll see some warnings that "String continuations are not recommended". I'm not addressing those right now.

[Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/doc.20format.20for.20JS/near/265209466).

r? `@GuillaumeGomez`
…yaahc

kmc-solid: Add `std::sys::solid::fs::File::read_buf`

This PR adds `std::sys::solid::fs::File::read_buf` to catch up with the changes introduced by rust-lang#81156 and fix the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets..
Change Backtrace::enabled atomic from SeqCst to Relaxed

This atomic is not synchronizing anything outside of its own value, so we don't need the `Acquire`/`Release` guarantee that all memory operations prior to the store are visible after the subsequent load, nor the `SeqCst` guarantee of all threads seeing all of the sequentially consistent operations in the same order.

Using `Relaxed` reduces the overhead of `Backtrace::capture()` in the case that backtraces are not enabled.

## Benchmark

```rust
#![feature(backtrace)]

use std::backtrace::Backtrace;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::thread;
use std::time::Instant;

fn main() {
    let begin = Instant::now();
    let mut threads = Vec::new();
    for _ in 0..64 {
        threads.push(thread::spawn(|| {
            for _ in 0..10_000_000 {
                let _ = Backtrace::capture();
                static LOL: AtomicUsize = AtomicUsize::new(0);
                LOL.store(1, Ordering::Release);
            }
        }));
    }
    for thread in threads {
        let _ = thread.join();
    }
    println!("{:?}", begin.elapsed());
}
```

**Before:** 6.73 seconds
**After:** 5.18 seconds
…n514

Don't emit shared files when scraping examples from dependencies in Rustdoc

This PR fixes rust-lang#91605. The issue is that `Context::init` gets called when scraping dependencies. By default, just calling `init` calls into `write_shared` and `build_index` which register the scraped crate into a list that later gets used for the Rustdoc sidebar. The fix is to ensure that `write_shared` is not called when scraping.

r? `@jyn514`
Quote bat script command line

Fixes rust-lang#91991

[`CreateProcessW`](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw#parameters) should only be used to run exe files but it does have some (undocumented) special handling for files with `.bat` and `.cmd` extensions. Essentially those magic extensions will cause the parameters to be automatically rewritten. Example pseudo Rust code (note that `CreateProcess` starts with an optional application name followed by the application arguments):
```rust
// These arguments...
CreateProcess(None, `@"foo.bat` "hello world""`@,` ...);
// ...are rewritten as
CreateProcess(Some(r"C:\Windows\System32\cmd.exe"), `@""foo.bat` "hello world"""`@,` ...);
```

However, when setting the first parameter (the application name) as we now do, it will omit the extra level of quotes around the arguments:

```rust
// These arguments...
CreateProcess(Some("foo.bat"), `@"foo.bat` "hello world""`@,` ...);
// ...are rewritten as
CreateProcess(Some(r"C:\Windows\System32\cmd.exe"), `@"foo.bat` "hello world""`@,` ...);
```

This means the arguments won't be passed to the script as intended.

Note that running batch files this way is undocumented but people have relied on this so we probably shouldn't break it.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 22, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Dec 22, 2021

📌 Commit 3afed8f has been approved by matthiaskrgr

@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 Dec 22, 2021
@bors
Copy link
Contributor

bors commented Dec 23, 2021

⌛ Testing commit 3afed8f with merge 5aa0239...

@bors
Copy link
Contributor

bors commented Dec 23, 2021

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 5aa0239 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 23, 2021
@bors bors merged commit 5aa0239 into rust-lang:master Dec 23, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 23, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (5aa0239): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@matthiaskrgr matthiaskrgr deleted the rollup-luplvuc branch January 2, 2022 22:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc 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