Skip to content

Commit 16fbef1

Browse files
committed
Auto merge of #151051 - JonathanBrouwer:rollup-SuaGLmP, r=JonathanBrouwer
Rollup of 14 pull requests Successful merges: - rust-lang/rust#150151 (Destabilise `target-spec-json`) - rust-lang/rust#150826 (Add `f16` inline ASM support for s390x) - rust-lang/rust#150883 (Improve span for "unresolved intra doc link" on `deprecated` attribute) - rust-lang/rust#150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - rust-lang/rust#150943 (Port `#[must_not_suspend]` to attribute parser) - rust-lang/rust#150990 (std: sys: net: uefi: Make TcpStream Send) - rust-lang/rust#150995 (core: ptr: split_at_mut: fix typo in safety doc) - rust-lang/rust#150998 (Relax test expectation for @__llvm_profile_runtime_user) - rust-lang/rust#151002 (Remove a workaround for a bug (take 2)) - rust-lang/rust#151005 (Fix typo in `MaybeUninit` docs) - rust-lang/rust#151011 (Update books) - rust-lang/rust#151029 (rustc-dev-guide subtree update) - rust-lang/rust#151032 (fix: added missing backtick in triagebot.toml) - rust-lang/rust#151035 (Don't suggest replacing closure parameter with type name) r? @ghost
2 parents 5108d15 + 4f8a3ff commit 16fbef1

File tree

11 files changed

+231
-227
lines changed

11 files changed

+231
-227
lines changed

ci/sembr/src/main.rs

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ static REGEX_SPLIT: LazyLock<Regex> =
2727
LazyLock::new(|| Regex::new(r"([^\.\d\-\*]\.|[^r]\?|!)\s").unwrap());
2828
// list elements, numbered (1.) or not (- and *)
2929
static REGEX_LIST_ENTRY: LazyLock<Regex> =
30-
LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*)\s+").unwrap());
30+
LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*|\d\))\s+").unwrap());
3131

3232
fn main() -> Result<()> {
3333
let cli = Cli::parse();
@@ -80,6 +80,7 @@ fn ignore(line: &str, in_code_block: bool) -> bool {
8080
in_code_block
8181
|| line.to_lowercase().contains("e.g.")
8282
|| line.to_lowercase().contains("n.b.")
83+
|| line.contains(" etc.")
8384
|| line.contains("i.e.")
8485
|| line.contains("et. al")
8586
|| line.contains('|')
@@ -189,9 +190,11 @@ must! be. split?
189190
ignore | tables
190191
ignore e.g. and
191192
ignore i.e. and
193+
ignore etc. and
192194
ignore E.g. too
193195
- list. entry
194196
* list. entry
197+
1) list. entry
195198
```
196199
some code. block
197200
```
@@ -212,11 +215,14 @@ split?
212215
ignore | tables
213216
ignore e.g. and
214217
ignore i.e. and
218+
ignore etc. and
215219
ignore E.g. too
216220
- list.
217221
entry
218222
* list.
219223
entry
224+
1) list.
225+
entry
220226
```
221227
some code. block
222228
```

rust-version

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
85c8ff69cb3efd950395cc444a54bbbdad668865
1+
44a5b55557c26353f388400d7da95527256fe260

src/ambig-unambig-ty-and-consts.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ parse.
66

77
```rust
88
fn func<T, const N: usize>(arg: T) {
9-
// ^ Unambig type position
9+
// ^ Unambig type position
1010
let a: _ = arg;
1111
// ^ Unambig type position
1212

@@ -108,4 +108,4 @@ This has a number of benefits:
108108
[`ast::AnonConst`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.AnonConst.html
109109
[`hir::GenericArg::Infer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Infer
110110
[`ast::ExprKind::Underscore`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html#variant.Underscore
111-
[`ast::Ty::Path(N)`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.TyKind.html#variant.Path
111+
[`ast::Ty::Path(N)`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.TyKind.html#variant.Path

src/building/new-target.md

Lines changed: 27 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
# Adding a new target
22

3-
These are a set of steps to add support for a new target. There are
4-
numerous end states and paths to get there, so not all sections may be
3+
These are a set of steps to add support for a new target.
4+
There are numerous end states and paths to get there, so not all sections may be
55
relevant to your desired goal.
66

77
See also the associated documentation in the [target tier policy].
@@ -11,8 +11,8 @@ See also the associated documentation in the [target tier policy].
1111
## Specifying a new LLVM
1212

1313
For very new targets, you may need to use a different fork of LLVM
14-
than what is currently shipped with Rust. In that case, navigate to
15-
the `src/llvm-project` git submodule (you might need to run `./x
14+
than what is currently shipped with Rust.
15+
In that case, navigate to the `src/llvm-project` git submodule (you might need to run `./x
1616
check` at least once so the submodule is updated), check out the
1717
appropriate commit for your fork, then commit that new submodule
1818
reference in the main Rust repository.
@@ -31,11 +31,9 @@ git commit -m 'Use my custom LLVM'
3131
### Using pre-built LLVM
3232

3333
If you have a local LLVM checkout that is already built, you may be
34-
able to configure Rust to treat your build as the system LLVM to avoid
35-
redundant builds.
34+
able to configure Rust to treat your build as the system LLVM to avoid redundant builds.
3635

37-
You can tell Rust to use a pre-built version of LLVM using the `target` section
38-
of `bootstrap.toml`:
36+
You can tell Rust to use a pre-built version of LLVM using the `target` section of `bootstrap.toml`:
3937

4038
```toml
4139
[target.x86_64-unknown-linux-gnu]
@@ -48,8 +46,8 @@ before, though they may be different from your system:
4846
- `/usr/bin/llvm-config-8`
4947
- `/usr/lib/llvm-8/bin/llvm-config`
5048

51-
Note that you need to have the LLVM `FileCheck` tool installed, which is used
52-
for codegen tests. This tool is normally built with LLVM, but if you use your
49+
Note that you need to have the LLVM `FileCheck` tool installed, which is used for codegen tests.
50+
This tool is normally built with LLVM, but if you use your
5351
own preinstalled LLVM, you will need to provide `FileCheck` in some other way.
5452
On Debian-based systems, you can install the `llvm-N-tools` package (where `N`
5553
is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify
@@ -58,8 +56,8 @@ or you can disable codegen test with the `codegen-tests` item in `bootstrap.toml
5856

5957
## Creating a target specification
6058

61-
You should start with a target JSON file. You can see the specification
62-
for an existing target using `--print target-spec-json`:
59+
You should start with a target JSON file.
60+
You can see the specification for an existing target using `--print target-spec-json`:
6361

6462
```
6563
rustc -Z unstable-options --target=wasm32-unknown-unknown --print target-spec-json
@@ -70,42 +68,22 @@ Save that JSON to a file and modify it as appropriate for your target.
7068
### Adding a target specification
7169

7270
Once you have filled out a JSON specification and been able to compile
73-
somewhat successfully, you can copy the specification into the
74-
compiler itself.
71+
somewhat successfully, you can copy the specification into the compiler itself.
7572

7673
You will need to add a line to the big table inside of the
77-
`supported_targets` macro in the `rustc_target::spec` module. You
78-
will then add a corresponding file for your new target containing a
74+
`supported_targets` macro in the `rustc_target::spec` module.
75+
You will then add a corresponding file for your new target containing a
7976
`target` function.
8077

8178
Look for existing targets to use as examples.
8279

83-
After adding your target to the `rustc_target` crate you may want to add
84-
`core`, `std`, ... with support for your new target. In that case you will
85-
probably need access to some `target_*` cfg. Unfortunately when building with
86-
stage0 (a precompiled compiler), you'll get an error that the target cfg is
87-
unexpected because stage0 doesn't know about the new target specification and
88-
we pass `--check-cfg` in order to tell it to check.
89-
90-
To fix the errors you will need to manually add the unexpected value to the
91-
different `Cargo.toml` in `library/{std,alloc,core}/Cargo.toml`. Here is an
92-
example for adding `NEW_TARGET_ARCH` as `target_arch`:
93-
94-
*`library/std/Cargo.toml`*:
95-
```diff
96-
[lints.rust.unexpected_cfgs]
97-
level = "warn"
98-
check-cfg = [
99-
'cfg(bootstrap)',
100-
- 'cfg(target_arch, values("xtensa"))',
101-
+ # #[cfg(bootstrap)] NEW_TARGET_ARCH
102-
+ 'cfg(target_arch, values("xtensa", "NEW_TARGET_ARCH"))',
103-
```
104-
105-
To use this target in bootstrap, we need to explicitly add the target triple to the `STAGE0_MISSING_TARGETS`
106-
list in `src/bootstrap/src/core/sanity.rs`. This is necessary because the default compiler bootstrap uses does
107-
not recognize the new target we just added. Therefore, it should be added to `STAGE0_MISSING_TARGETS` so that the
108-
bootstrap is aware that this target is not yet supported by the stage0 compiler.
80+
To use this target in bootstrap, we need to explicitly add the target triple to
81+
the `STAGE0_MISSING_TARGETS` list in `src/bootstrap/src/core/sanity.rs`.
82+
This is necessary because the default bootstrap compiler (typically a beta compiler)
83+
does not recognize the new target we just added.
84+
Therefore, it should be added to
85+
`STAGE0_MISSING_TARGETS` so that the bootstrap is aware that this target is not
86+
yet supported by the stage0 compiler.
10987

11088
```diff
11189
const STAGE0_MISSING_TARGETS: &[&str] = &[
@@ -116,9 +94,9 @@ const STAGE0_MISSING_TARGETS: &[&str] = &[
11694
## Patching crates
11795

11896
You may need to make changes to crates that the compiler depends on,
119-
such as [`libc`][] or [`cc`][]. If so, you can use Cargo's
120-
[`[patch]`][patch] ability. For example, if you want to use an
121-
unreleased version of `libc`, you can add it to the top-level
97+
such as [`libc`][] or [`cc`][].
98+
If so, you can use Cargo's [`[patch]`][patch] ability.
99+
For example, if you want to use an unreleased version of `libc`, you can add it to the top-level
122100
`Cargo.toml` file:
123101

124102
```diff
@@ -138,9 +116,9 @@ index 1e83f05e0ca..4d0172071c1 100644
138116
After this, run `cargo update -p libc` to update the lockfiles.
139117

140118
Beware that if you patch to a local `path` dependency, this will enable
141-
warnings for that dependency. Some dependencies are not warning-free, and due
142-
to the `deny-warnings` setting in `bootstrap.toml`, the build may suddenly start
143-
to fail.
119+
warnings for that dependency.
120+
Some dependencies are not warning-free, and due
121+
to the `deny-warnings` setting in `bootstrap.toml`, the build may suddenly start to fail.
144122
To work around warnings, you may want to:
145123
- Modify the dependency to remove the warnings
146124
- Or for local development purposes, suppress the warnings by setting deny-warnings = false in bootstrap.toml.
@@ -157,8 +135,7 @@ deny-warnings = false
157135

158136
## Cross-compiling
159137

160-
Once you have a target specification in JSON and in the code, you can
161-
cross-compile `rustc`:
138+
Once you have a target specification in JSON and in the code, you can cross-compile `rustc`:
162139

163140
```
164141
DESTDIR=/path/to/install/in \

src/const-generics.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -111,14 +111,15 @@ The third point is also somewhat subtle, by not inheriting any of the where clau
111111

112112
This also makes it much more likely that the compiler will ICE or atleast incidentally emit some kind of error if we *do* accidentally allow generic parameters in an anon const, as the anon const will have none of the necessary information in its environment to properly handle the generic parameters.
113113

114+
#### Array repeat expressions
115+
The one exception to all of the above is repeat counts of array expressions. As a *backwards compatibility hack* we allow the repeat count const argument to use generic parameters.
116+
114117
```rust
115118
fn foo<T: Sized>() {
116-
let a = [1_u8; size_of::<*mut T>()];
119+
let a = [1_u8; size_of::<T>()];
117120
}
118121
```
119122

120-
The one exception to all of the above is repeat counts of array expressions. As a *backwards compatibility hack* we allow the repeat count const argument to use generic parameters.
121-
122123
However, to avoid most of the problems involved in allowing generic parameters in anon const const arguments we require that the constant be evaluated before monomorphization (e.g. during type checking). In some sense we only allow generic parameters here when they are semantically unused.
123124

124125
In the previous example the anon const can be evaluated for any type parameter `T` because raw pointers to sized types always have the same size (e.g. `8` on 64bit platforms).

src/external-repos.md

Lines changed: 33 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -29,9 +29,9 @@ The following external projects are managed using some form of a `subtree`:
2929

3030
In contrast to `submodule` dependencies
3131
(see below for those), the `subtree` dependencies are just regular files and directories which can
32-
be updated in tree. However, if possible, enhancements, bug fixes, etc. specific
33-
to these tools should be filed against the tools directly in their respective
34-
upstream repositories. The exception is that when rustc changes are required to
32+
be updated in-tree. However, if possible, enhancements, bug fixes, etc. specific
33+
to these tools should be filed against the tools directly in their respective upstream repositories.
34+
The exception is that when rustc changes are required to
3535
implement a new tool feature or test, that should happen in one collective rustc PR.
3636

3737
`subtree` dependencies are currently managed by two distinct approaches:
@@ -51,7 +51,9 @@ implement a new tool feature or test, that should happen in one collective rustc
5151

5252
### Josh subtrees
5353

54-
The [josh] tool is an alternative to git subtrees, which manages git history in a different way and scales better to larger repositories. Specific tooling is required to work with josh. We provide a helper [`rustc-josh-sync`][josh-sync] tool to help with the synchronization, described [below](#synchronizing-a-josh-subtree).
54+
The [josh] tool is an alternative to git subtrees, which manages git history in a different way and scales better to larger repositories.
55+
Specific tooling is required to work with josh.
56+
We provide a helper [`rustc-josh-sync`][josh-sync] tool to help with the synchronization, described [below](#synchronizing-a-josh-subtree).
5557

5658
### Synchronizing a Josh subtree
5759

@@ -69,24 +71,24 @@ changes from the subtree to rust-lang/rust) are performed from the subtree repos
6971
switch to its repository checkout directory in your terminal).
7072

7173
#### Performing pull
72-
1) Checkout a new branch that will be used to create a PR into the subtree
73-
2) Run the pull command
74+
1. Checkout a new branch that will be used to create a PR into the subtree
75+
2. Run the pull command
7476
```
7577
rustc-josh-sync pull
7678
```
77-
3) Push the branch to your fork and create a PR into the subtree repository
79+
3. Push the branch to your fork and create a PR into the subtree repository
7880
- If you have `gh` CLI installed, `rustc-josh-sync` can create the PR for you.
7981
8082
#### Performing push
8183
8284
> NOTE:
8385
> Before you proceed, look at some guidance related to Git [on josh-sync README].
8486
85-
1) Run the push command to create a branch named `<branch-name>` in a `rustc` fork under the `<gh-username>` account
87+
1. Run the push command to create a branch named `<branch-name>` in a `rustc` fork under the `<gh-username>` account
8688
```
8789
rustc-josh-sync push <branch-name> <gh-username>
8890
```
89-
2) Create a PR from `<branch-name>` into `rust-lang/rust`
91+
2. Create a PR from `<branch-name>` into `rust-lang/rust`
9092
9193
### Creating a new Josh subtree dependency
9294
@@ -97,7 +99,8 @@ If you want to migrate a repository dependency from `git subtree` or `git submod
9799
Periodically the changes made to subtree based dependencies need to be synchronized between this
98100
repository and the upstream tool repositories.
99101
100-
Subtree synchronizations are typically handled by the respective tool maintainers. Other users
102+
Subtree synchronizations are typically handled by the respective tool maintainers.
103+
Other users
101104
are welcome to submit synchronization PRs, however, in order to do so you will need to modify
102105
your local git installation and follow a very precise set of instructions.
103106
These instructions are documented, along with several useful tips and tricks, in the
@@ -108,8 +111,8 @@ use the correct corresponding subtree directory and remote repository.
108111
The synchronization process goes in two directions: `subtree push` and `subtree pull`.
109112
110113
A `subtree push` takes all the changes that happened to the copy in this repo and creates commits
111-
on the remote repo that match the local changes. Every local
112-
commit that touched the subtree causes a commit on the remote repo, but
114+
on the remote repo that match the local changes.
115+
Every local commit that touched the subtree causes a commit on the remote repo, but
113116
is modified to move the files from the specified directory to the tool repo root.
114117
115118
A `subtree pull` takes all changes since the last `subtree pull`
@@ -119,14 +122,17 @@ the tool changes into the specified directory in the Rust repository.
119122
It is recommended that you always do a push first and get that merged to the default branch of the tool.
120123
Then, when you do a pull, the merge works without conflicts.
121124
While it's definitely possible to resolve conflicts during a pull, you may have to redo the conflict
122-
resolution if your PR doesn't get merged fast enough and there are new conflicts. Do not try to
123-
rebase the result of a `git subtree pull`, rebasing merge commits is a bad idea in general.
125+
resolution if your PR doesn't get merged fast enough and there are new conflicts.
126+
Do not try to
127+
rebase the result of a `git subtree pull`; rebasing merge commits is a bad idea in general.
124128
125129
You always need to specify the `-P` prefix to the subtree directory and the corresponding remote
126-
repository. If you specify the wrong directory or repository
130+
repository.
131+
If you specify the wrong directory or repository
127132
you'll get very fun merges that try to push the wrong directory to the wrong remote repository.
128133
Luckily you can just abort this without any consequences by throwing away either the pulled commits
129-
in rustc or the pushed branch on the remote and try again. It is usually fairly obvious
134+
in rustc or the pushed branch on the remote and try again.
135+
It is usually fairly obvious
130136
that this is happening because you suddenly get thousands of commits that want to be synchronized.
131137
132138
[clippy-sync-docs]: https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html
@@ -140,33 +146,34 @@ repository's root directory!)
140146
git subtree add -P src/tools/clippy https://github.com/rust-lang/rust-clippy.git master
141147
```
142148
143-
This will create a new commit, which you may not rebase under any circumstances! Delete the commit
144-
and redo the operation if you need to rebase.
149+
This will create a new commit, which you may not rebase under any circumstances!
150+
Delete the commit and redo the operation if you need to rebase.
145151
146152
Now you're done, the `src/tools/clippy` directory behaves as if Clippy were
147153
part of the rustc monorepo, so no one but you (or others that synchronize
148154
subtrees) actually needs to use `git subtree`.
149155
150156
## External Dependencies (submodules)
151157
152-
Building Rust will also use external git repositories tracked using [git
153-
submodules]. The complete list may be found in the [`.gitmodules`] file. Some
154-
of these projects are required (like `stdarch` for the standard library) and
158+
Building Rust will also use external git repositories tracked using [git submodules].
159+
The complete list may be found in the [`.gitmodules`] file.
160+
Some of these projects are required (like `stdarch` for the standard library) and
155161
some of them are optional (like `src/doc/book`).
156162
157163
Usage of submodules is discussed more in the [Using Git chapter](git.md#git-submodules).
158164
159165
Some of the submodules are allowed to be in a "broken" state where they
160166
either don't build or their tests don't pass, e.g. the documentation books
161-
like [The Rust Reference]. Maintainers of these projects will be notified
162-
when the project is in a broken state, and they should fix them as soon
163-
as possible. The current status is tracked on the [toolstate website].
167+
like [The Rust Reference].
168+
Maintainers of these projects will be notified
169+
when the project is in a broken state, and they should fix them as soon as possible.
170+
The current status is tracked on the [toolstate website].
164171
More information may be found on the Forge [Toolstate chapter].
165172
In practice, it is very rare for documentation to have broken toolstate.
166173
167174
Breakage is not allowed in the beta and stable channels, and must be addressed
168-
before the PR is merged. They are also not allowed to be broken on `main` in
169-
the week leading up to the beta cut.
175+
before the PR is merged.
176+
They are also not allowed to be broken on `main` in the week leading up to the beta cut.
170177
171178
[git submodules]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
172179
[`.gitmodules`]: https://github.com/rust-lang/rust/blob/HEAD/.gitmodules

0 commit comments

Comments
 (0)