Rollup of 10 pull requests #77798
Merged
Rollup of 10 pull requests #77798
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <joshua@yottadb.com>
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.
Link Vec leak doc to Box
…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
|
📌 Commit c98b3e8 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
eat_while()in lexer #77629 (Cleanup ofeat_while()in lexer)changelog-seenin config.toml.example #77787 (Updatechangelog-seenin config.toml.example)Failed merges:
r? @ghost