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 10 pull requests #77798

Merged
merged 27 commits into from
Oct 10, 2020
Merged

Rollup of 10 pull requests #77798

merged 27 commits into from
Oct 10, 2020

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

follower and others added 27 commits September 26, 2020 03:26
Changed because it's not obvious how to get from the previously used URL to the documentation-specific content.

This is partly because the original URL was previously changed to point to different content:

 * https://github.com/rust-lang/rust/pull/74037/files#diff-242481015141f373dcb178e93cffa850L88

 * rust-lang@3f6928f#diff-6a3371457528722a734f3c51d9238c13L12
…er of UTF8 bytes.

Fixed it by inlining it in the two places where the count is used and simplified the logic there.
A few architectures in `os::linux::raw` import `libc::stat`, rather than
defining that type directly. However, that also imports the _function_
called `stat`, which makes this doc link ambiguous:

    error: `crate::os::linux::raw::stat` is both a struct and a function
      --> library/std/src/os/linux/fs.rs:21:19
       |
    21 |     /// [`stat`]: crate::os::linux::raw::stat
       |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous link
       |
       = note: `-D broken-intra-doc-links` implied by `-D warnings`
    help: to link to the struct, prefix with the item type
       |
    21 |     /// [`stat`]: struct@crate::os::linux::raw::stat
       |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    help: to link to the function, add parentheses
       |
    21 |     /// [`stat`]: crate::os::linux::raw::stat()
       |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We want the `struct`, so it's now prefixed accordingly.
s/abitrary/arbitrary/
This got out of sync when the version was bumped last time.

Long-term we may want to find an easier way to maintain this that
doesn't require bumping the version in three different places. Off the
top of my head I can't think of anything, though.
Co-authored-by: Joshua Nelson <[email protected]>
They should take boolean values and the current placeholders are confusing, at least for me.
Link to documentation-specific guidelines.

Changed contribution information URL because it's not obvious how to get from the current URL to the documentation-specific content.

The current URL points to this "Getting Started" page, which contains nothing specific about documentation[*] and instead launches into how to *build* `rustc` which is not a strict prerequisite for contributing documentation fixes:

 * https://rustc-dev-guide.rust-lang.org/getting-started.html

[*] The most specific content is a "Writing documentation" bullet point which is not itself a link to anything (I guess a patch for that might be helpful too).

### Why?

Making this change will make it easier for people who wish to make small "drive by" documentation fixes (and read contribution guidelines ;) ) which I find are often how I start contributing to a project. (Exhibit A: rust-lang#77050 :) )

### Background

My impression is the change of content linked is an unintentional change due to a couple of other changes:

 * Originally, the link pointed to  `contributing.md` which started with a "table of contents" linking to each section. But the content in `contributing.md` was removed and replaced with a link to the "Getting Started" section here:

    * rust-lang@3f6928f#diff-6a3371457528722a734f3c51d9238c13L1

   But the changed link doesn't actually point to the equivalent content, which is now located here:

    * https://rustc-dev-guide.rust-lang.org/contributing.html

   (If the "Guide to Rustc Development" is now considered the canonical location of "How to Contribute" content it might be a good idea to merge some of the "Contributing" Introduction section into the "Getting Started" section.)

 * This was then compounded by changing the link from `contributing.md` to  `contributing.html` here:

     * https://github.com/rust-lang/rust/pull/74037/files#diff-242481015141f373dcb178e93cffa850L88

    In order to even find the new location of the previous `contributing.md` content I ended up needing to do a GitHub search of the `rust-lang` org for the phrase "Documentation improvements are very welcome". :D
…rError, r=varkor

Cleanup of `eat_while()` in lexer

The size of a lexer Token was inflated by the largest `TokenKind` variants `LiteralKind::RawStr` and `RawByteStr`, because
* it used `usize` although `u32` is sufficient in rustc, since crates must be smaller than 4GB,
* and it stored the 20 bytes big `RawStrError` enum for error reporting.

If a raw string is invalid, it now needs to be reparsed to get the `RawStrError` data, but that is a very cold code path.

Technically this breaks other tools that depend on rustc_lexer because they are now also restricted to a max file size of 4GB. But this shouldn't matter in practice, and rustc_lexer isn't stable anyway.

Can I also get a perf run?

Edit: This makes no difference in performance. The PR now only contains a small cleanup.
…t, r=Amanieu

fix __rust_alloc_error_handler comment

`__rust_alloc_error_handler` was added in the same `extern` block as the allocator functions, but the comment there was not actually correct for `__rust_alloc_error_handler`. So move it down to the rest of the default allocator handling with a fixed comment. At least the comment reflects my understanding of what happens, please check carefully. :)

r? @Amanieu Cc @haraldh
…henkov

Dead code cleanup in windows-gnu std

Closes rust-lang#77622

This is the only leftover I could find.
…matthewjasper

Add TraitDef::find_map_relevant_impl

This PR adds a method to `TraitDef`. While `for_each_relevant_impl` covers the general use case, sometimes it's not necessary to scan through all the relevant implementations, so this PR introduces a new method, `find_map_relevant_impl`. I've also replaced the `for_each_relevant_impl` calls where possible.

I'm hoping for a tiny bit of efficiency gain here and there.
Clarify the debug-related values should take boolean

rust-lang#76588 tweaked their placeholders but these values should take boolean and the current placeholders are confusing, at least for me.
doc: disambiguate stat in MetadataExt::as_raw_stat

A few architectures in `os::linux::raw` import `libc::stat`, rather than
defining that type directly. However, that also imports the _function_
called `stat`, which makes this doc link ambiguous:

    error: `crate::os::linux::raw::stat` is both a struct and a function
      --> library/std/src/os/linux/fs.rs:21:19
       |
    21 |     /// [`stat`]: crate::os::linux::raw::stat
       |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous link
       |
       = note: `-D broken-intra-doc-links` implied by `-D warnings`
    help: to link to the struct, prefix with the item type
       |
    21 |     /// [`stat`]: struct@crate::os::linux::raw::stat
       |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    help: to link to the function, add parentheses
       |
    21 |     /// [`stat`]: crate::os::linux::raw::stat()
       |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We want the `struct`, so it's now prefixed accordingly.
Fix typo in error code description

s/abitrary/arbitrary/
…orino

Update `changelog-seen` in config.toml.example

This got out of sync when the version was bumped last time in rust-lang#77133

Long-term we may want to find an easier way to maintain this that
doesn't require bumping the version in three different places. Off the
top of my head I can't think of anything, though. It _is_ documented in src/bootstrap/README.md, although I don't know how many people read that.

r? @Mark-Simulacrum
cc @spastorino
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=5
@rustbot modify labels: rollup

@bors
Copy link
Contributor

bors commented Oct 10, 2020

📌 Commit c98b3e8 has been approved by JohnTitor

@rustbot rustbot added the rollup A PR which is a rollup label Oct 10, 2020
@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 10, 2020
@bors
Copy link
Contributor

bors commented Oct 10, 2020

⌛ Testing commit c98b3e8 with merge 790d19c...

@bors
Copy link
Contributor

bors commented Oct 10, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: JohnTitor
Pushing 790d19c to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 10, 2020
@bors bors merged commit 790d19c into rust-lang:master Oct 10, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 10, 2020
@JohnTitor JohnTitor deleted the rollup-82u711m branch October 10, 2020 21:45
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.