For consistency with normal functions.

Related to rust-lang#117925

…e def id

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Currently the documentation of `FileExt::seek_write` on Windows
indicates that writes beyond the end of the file leave intermediate
bytes uninitialized. This commentary dates back to the original
inclusion of these functions in rust-lang#35704 (wow blast from the past!). At
the time the functionality here was implemented using `WriteFile`, but
nowadays the `NtWriteFile` method is used instead. The documentation for
`NtWriteFile` explicitly states:

> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.

This commentary has had a downstream impact in the `system-interface`
crate where it tries to handle this by explicitly writing zeros, but I
don't believe that's necessary any more. I'm sending a PR upstream here
to avoid future confusion and codify that zeros are written in the
intermediate bytes matching what Windows currently provides.

Because it can be used for a lifetime or a label.

…r literal.

Currently the parser will interpret any label/lifetime in certain
positions as a mistyped char literal, on the assumption that the
trailing single quote was accidentally omitted. This is reasonable for a
something like 'a (because 'a' would be valid) but not reasonable for a
something like 'abc (because 'abc' is not valid).

This commit restricts this behaviour only to labels/lifetimes that would
be valid char literals, via the new `could_be_unclosed_char_literal`
function. The commit also augments the `label-is-actually-char.rs` test
in a couple of ways:
- Adds testing of labels/lifetimes with identifiers longer than one
  char, e.g. 'abc.
- Adds a new match with simpler patterns, because the
  `recover_unclosed_char` call in `parse_pat_with_range_pat` was not
  being exercised (in this test or any other ui tests).

Fixes rust-lang#120397, an assertion failure, which was caused by this behaviour
in the parser interacting with some new stricter char literal checking
added in rust-lang#120329.

Issue tests numbered 1920, 3668, 5997, 23302, 32122, 40510, 57741, 71676, and 76077 were moved to relevant better-named subdirectories. ISSUES_ENTRY_LIMIT was adjusted to match new number of files and FIXME note was expanded.

Because it's almost always static.

This makes `impl IntoDiagnosticArg for DiagnosticArgValue` trivial,
which is nice.

There are a few diagnostics constructed in
`compiler/rustc_mir_build/src/check_unsafety.rs` and
`compiler/rustc_mir_transform/src/errors.rs` that now need symbols
converted to `String` with `to_string` instead of `&str` with `as_str`,
but that' no big deal, and worth it for the simplifications elsewhere.

Because the `&'a str` fields can be trivially converted to `String`
without causing any extra allocations.

It's identical to the one in `rustc_errors`; use that instead.

Also remove some `rustc_errors::` qualifiers.

Because it's always 'static.

Because it's always static.

I'm surprised the compiler allowed this unused lifetime without any
complaint.

…=Nilstrieb

Add triagebot mentions entry for simd intrinsics

Fixes rust-lang#119119

cc `@antoyo,` `@GuillaumeGomez,` `@rust-lang/project-portable-simd`

Reject infinitely-sized reads from io::Repeat

These calls would always run out of memory.

Related to rust-lang#117925

…Simulacrum

bootstrap: add more unit tests

self-explanatory

rustdoc: Prevent JS injection from localStorage

It turns out that you can execute arbitrary JavaScript on the rustdocs settings page. Here's how:

1. Open `settings.html` on a rustdocs site.
2. Set "preferred light theme" to "dark" to initialize the corresponding localStorage value.
3. Plant a payload by executing this in your browser's dev console: ``Object.keys(localStorage).forEach(key=>localStorage.setItem(key,`javascript:alert()//*/javascript:javascript:"/*'/*\`/*--></noscript></title></textarea></style></template></noembed></script><html " onmouseover=/*&lt;svg/*/onload=alert()onload=alert()//><svg onload=alert()><svg onload=alert()>*/</style><script>alert()</script><style>`));``
4. Refresh the page -- you should see an alert.

This could be particularly dangerous if rustdocs are deployed on a domain hosting some other application. Malicious code could circumvent `same-origin` policies and do mischievous things with user data.

This change ensures that only defined themes can actually be selected (arbitrary strings from localStorage will not be written to the document), and for good measure sanitizes the theme name.

Update codegen test for LLVM 18

r? ```````@cuviper```````

…li-obk

interpret/memory: fix safety comment for large array memset optimization

Also fix the doc comment for `check_and_deref_ptr`.

…i-obk

Bound errors span label cleanup

Consolidate span labels for "this type doesn't satisfy a bound" for more compact diagnostic output.

…tree, r=cjgillot

Make the coroutine def id of an async closure the child of the closure def id

Adjust def collection to make the (inner) coroutine returned by an async closure be a def id child of the (outer) closure. This makes it easy to map from coroutine -> closure by using `tcx.parent`, since currently it's not trivial to do this.

…, r=onur-ozkan

Add instructions of how to use pre-vendored 'rustc-src'

This PR closes rust-lang#110163.

I had to move the URL to the left, making it not aligned as it is three lines above, but the tidy check would yell at me otherwise. If that's not acceptable, I'd love some suggestions on how to make it better.

One question: in the original issue (rust-lang#110163 (comment)), it was suggested to mention how to download specific commit tarballs; however, it was said it's not documented anywhere, so I did not include that yet. If there is a want to have that, I'd gladly amend the commit.

raw pointer metadata API: data address -> data pointer

A pointer consists of [more than just an address](rust-lang/rfcs#3559), so let's not equate "pointer" and "address" in these docs.

…Nilstrieb

Remove unnecessary unit returns in query declarations

For consistency with normal functions.

…nethercote

Move UI issue tests to subdirectories

I've moved issue tests numbered 1920, 3668, 5997, 23302, 32122, 40510, 57741, 71676, and 76077 to relevant better-named subdirectories (tracking issue rust-lang#73494). The issues were chosen by having the highest number of files per issue.

I adjusted the `ISSUES_ENTRY_LIMIT` because `tidy` was shouting at me.

…ement, r=fmease

Fixes footnote handling in rustdoc

Fixes rust-lang#100638.

You can now declare footnotes like this:

```rust
//! Reference to footnotes A[^1], B[^2] and C[^3].
//!
//! [^1]: Footnote A.
//! [^2]: Footnote B.
//! [^3]: Footnote C.
```

r? `@notriddle`

…rite-docs, r=ChrisDenton

std: Update documentation of seek_write on Windows

Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in rust-lang#35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states:

> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.

This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.

…-errors

Be more careful about interpreting a label/lifetime as a mistyped char literal.

Currently the parser interprets any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. In such cases it gives an error with a suggestion to add the trailing single quote, and then puts the appropriate char literal into the AST. This behaviour was introduced in rust-lang#101293.

This is reasonable for a case like this:
```
let c = 'a;
```
because `'a'` is a valid char literal. It's less reasonable for a case like this:
```
let c = 'abc;
```
because `'abc'` is not a valid char literal.

Prior to rust-lang#120329 this could result in some sub-optimal suggestions in error messages, but nothing else. But rust-lang#120329 changed `LitKind::from_token_lit` to assume that the char/byte/string literals it receives are valid, and to assert if not. This is reasonable because the lexer does not produce invalid char/byte/string literals in general. But in this "interpret label/lifetime as unclosed char literal" case the parser can produce an invalid char literal with contents such as `abc`, which triggers an assertion failure.

This PR changes the parser so it's more cautious about interpreting labels/lifetimes as unclosed char literals.

Fixes rust-lang#120397.

r? `@compiler-errors`

…avidtwco

Add matthewjasper to some review groups

r? `@davidtwco`

Update books

## rust-lang/edition-guide

1 commits in bbffb074e16bef89772818b400b6c76a65eac126..baafacc6d8701269dab1e1e333f3547fb54b5a59
2024-01-18 18:44:06 UTC to 2024-01-18 18:44:06 UTC

- Update c-string literal stabilization release number. (rust-lang/edition-guide#289)

## rust-embedded/book

1 commits in 3f9df2b9885c6741365da2e12ed6662cd0e827d6..2e95fc2fd31d669947e993aa07ef10dc9828bee7
2024-01-29 07:19:07 UTC to 2024-01-29 07:19:07 UTC

- Mention generics in "optimizing dependencies" (rust-embedded/book#366)

## rust-lang/reference

3 commits in 8c77e8be9da1a9c70545556218d563c8d061f1fd..a0b119535e7740f68494c4f0582f7ad008b00ccd
2024-01-27 19:22:06 UTC to 2024-01-27 16:43:49 UTC

- Update C-String literals to reject NUL (rust-lang/reference#1450)
- pure asm blocks must terminate (rust-lang/reference#1442)
- String literal expressions (rust-lang/reference#1452)

## rust-lang/rust-by-example

4 commits in ddf5cb0e6ee54ba2dd84c8ca3e1314120014e20d..179256a445d6144f5f371fdefb993f48f33978b0
2024-01-22 12:21:42 UTC to 2024-01-20 23:10:42 UTC

- Updated first sentence of "parsing a string" in string.md (rust-lang/rust-by-example#1805)
- Update the rustdoc example to match best practice (rust-lang/rust-by-example#1804)
- Add reference to crates.io error handling crates (rust-lang/rust-by-example#1803)
- fix(str.md): avoid misunderstanding that there were only two string types (rust-lang/rust-by-example#1802)

## rust-lang/rustc-dev-guide

15 commits in 4af29d1a7f64f88a36539662c6a84fe1fbe6cde1..ec287e332777627185be4798ad22599ffe7b84aa
2024-01-28 22:45:18 UTC to 2024-01-15 17:44:49 UTC

- Upgrade actions to use Node.js v20 (rust-lang/rustc-dev-guide#1863)
- Fix some links (rust-lang/rustc-dev-guide#1865)
- Add link in salsa (rust-lang/rustc-dev-guide#1866)
- Clarify what rt.rs is. (rust-lang/rustc-dev-guide#1876)
- update link to rustc dependencies (rust-lang/rustc-dev-guide#1869)
- Followup to rust-lang#1862 (rust-lang/rustc-dev-guide#1864)
- Clarify debugging graph dependency (rust-lang/rustc-dev-guide#1862)
- Get diagnostics directly in `rustc-driver-getting-diagnostics` example (rust-lang/rustc-dev-guide#1857)
- Update examples (rust-lang/rustc-dev-guide#1856)
- Add a perf. bot command and a link to its help page (rust-lang/rustc-dev-guide#1855)
- Add some explanations for frequently used rustbot commands (rust-lang/rustc-dev-guide#1849)
- update some of the diagnostic translations info (rust-lang/rustc-dev-guide#1711)
- Document unsafety checking (rust-lang/rustc-dev-guide#1847)
- Remove outdated references to `-Z dump-mir-spanview` (rust-lang/rustc-dev-guide#1853)
- update old bootstrap docs (rust-lang/rustc-dev-guide#1852)

Diagnostic lifetimes cleanups

Some diagnostic simplifications.

r? `@oli-obk`