You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/doc/rustc-dev-guide/src/coroutine-closures.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -167,7 +167,7 @@ We introduce a `AsyncFnKindHelper` trait which allows us to defer the question o
167
167
168
168
This seems a bit roundabout and complex, and I admit that it is. But let's think of the "do nothing" alternative -- we could instead mark all `AsyncFn*` goals as ambiguous until upvar analysis, at which point we would know exactly what to put into the upvars of the coroutine we return. However, this is actually *very* detrimental to inference in the program, since it means that programs like this would not be valid:
169
169
170
-
```rust!
170
+
```rust,ignore
171
171
let c = async || -> String { .. };
172
172
let s = c().await;
173
173
// ^^^ If we can't project `<{c} as AsyncFn>::call()` to a coroutine, then the `IntoFuture::into_future` call inside of the `.await` stalls, and the type of `s` is left unconstrained as an infer var.
**Please ask questions!** A lot of people report feeling that they are "wasting
39
-
expert's time", but nobody on `t-compiler` feels this way. Contributors are
40
-
important to us.
40
+
expert's time", but nobody on `t-compiler` feels this way.
41
+
Contributors are important to us.
41
42
42
43
Also, if you feel comfortable, prefer public topics, as this means others can
43
-
see the questions and answers, and perhaps even integrate them back into this
44
-
guide :)
44
+
see the questions and answers, and perhaps even integrate them back into this guide :)
45
45
46
-
**Tip**: If you're not a native English speaker and feel unsure about writing, try using a translator to help. But avoid using LLM tools that generate long, complex words. In daily teamwork, **simple and clear words** are best for easy understanding. Even small typos or grammar mistakes can make you seem more human, and people connect better with humans.
46
+
**Tip**: If you're not a native English speaker and feel unsure about writing, try using a translator to help.
47
+
But avoid using LLM tools that generate long, complex words.
48
+
In daily teamwork, **simple and clear words** are best for easy understanding.
49
+
Even small typos or grammar mistakes can make you seem more human, and people connect better with humans.
47
50
48
51
### Experts
49
52
50
-
Not all `t-compiler` members are experts on all parts of `rustc`; it's a
51
-
pretty large project. To find out who could have some expertise on
53
+
Not all `t-compiler` members are experts on all parts of `rustc`;
54
+
it's a pretty large project.
55
+
To find out who could have some expertise on
52
56
different parts of the compiler, [consult triagebot assign groups][map].
53
-
The sections that start with `[assign*` in `triagebot.toml` file.
57
+
The sections that start with `[assign*` in `triagebot.toml` file.
54
58
But also, feel free to ask questions even if you can't figure out who to ping.
55
59
56
60
Another way to find experts for a given part of the compiler is to see who has made recent commits.
57
61
For example, to find people who have recently worked on name resolution since the 1.68.2 release,
58
-
you could run `git shortlog -n 1.68.2.. compiler/rustc_resolve/`. Ignore any commits starting with
62
+
you could run `git shortlog -n 1.68.2.. compiler/rustc_resolve/`.
63
+
Ignore any commits starting with
59
64
"Rollup merge" or commits by `@bors` (see [CI contribution procedures](./contributing.md#ci) for
60
65
more information about these commits).
61
66
@@ -64,8 +69,7 @@ more information about these commits).
64
69
### Etiquette
65
70
66
71
We do ask that you be mindful to include as much useful information as you can
67
-
in your question, but we recognize this can be hard if you are unfamiliar with
68
-
contributing to Rust.
72
+
in your question, but we recognize this can be hard if you are unfamiliar with contributing to Rust.
69
73
70
74
Just pinging someone without providing any context can be a bit annoying and
71
75
just create noise, so we ask that you be mindful of the fact that the
@@ -74,13 +78,16 @@ just create noise, so we ask that you be mindful of the fact that the
74
78
## What should I work on?
75
79
76
80
The Rust project is quite large and it can be difficult to know which parts of the project need
77
-
help, or are a good starting place for beginners. Here are some suggested starting places.
81
+
help, or are a good starting place for beginners.
82
+
Here are some suggested starting places.
78
83
79
84
### Easy or mentored issues
80
85
81
86
If you're looking for somewhere to start, check out the following [issue
82
-
search][help-wanted-search]. See the [Triage] for an explanation of these labels. You can also try
83
-
filtering the search to areas you're interested in. For example:
87
+
search][help-wanted-search].
88
+
See the [Triage] for an explanation of these labels.
89
+
You can also try filtering the search to areas you're interested in.
90
+
For example:
84
91
85
92
-`repo:rust-lang/rust-clippy` will only show clippy issues
86
93
-`label:T-compiler` will only show issues related to the compiler
@@ -94,8 +101,9 @@ See below for how to find work that isn't labelled.
94
101
95
102
### Recurring work
96
103
97
-
Some work is too large to be done by a single person. In this case, it's common to have "Tracking
98
-
issues" to co-ordinate the work between contributors. Here are some example tracking issues where
104
+
Some work is too large to be done by a single person.
105
+
In this case, it's common to have "Tracking issues" to co-ordinate the work between contributors.
106
+
Here are some example tracking issues where
99
107
it's easy to pick up work without a large time commitment:
100
108
101
109
-*Add recurring work items here.*
@@ -105,8 +113,8 @@ If you find more recurring work, please feel free to add it here!
105
113
### Clippy issues
106
114
107
115
The [Clippy] project has spent a long time making its contribution process as friendly to newcomers
108
-
as possible. Consider working on it first to get familiar with the process and the compiler
109
-
internals.
116
+
as possible.
117
+
Consider working on it first to get familiar with the process and the compiler internals.
110
118
111
119
See [the Clippy contribution guide][clippy-contributing] for instructions on getting started.
112
120
@@ -116,27 +124,33 @@ See [the Clippy contribution guide][clippy-contributing] for instructions on get
116
124
### Diagnostic issues
117
125
118
126
Many diagnostic issues are self-contained and don't need detailed background knowledge of the
119
-
compiler. You can see a list of diagnostic issues [here][diagnostic-issues].
127
+
compiler.
128
+
You can see a list of diagnostic issues [here][diagnostic-issues].
Issues that have been resolved but do not have a regression test are marked with the `E-needs-test` label. Writing unit tests is a low-risk, lower-priority task that offers new contributors a great opportunity to familiarize themselves with the testing infrastructure and contribution workflow.
150
+
Issues that have been resolved but do not have a regression test are marked with the `E-needs-test` label.
151
+
Writing unit tests is a low-risk,
152
+
lower-priority task that offers new contributors a great opportunity to familiarize themselves
153
+
with the testing infrastructure and contribution workflow.
140
154
141
155
### Contributing to std (standard library)
142
156
@@ -147,28 +161,28 @@ See [std-dev-guide](https://std-dev-guide.rust-lang.org/).
147
161
There are a bunch of other projects that you can contribute to outside of the
148
162
`rust-lang/rust` repo, including `cargo`, `miri`, `rustup`, and many others.
149
163
150
-
These repos might have their own contributing guidelines and procedures. Many
151
-
of them are owned by working groups. For more info, see the documentation in those repos' READMEs.
164
+
These repos might have their own contributing guidelines and procedures.
165
+
Many of them are owned by working groups.
166
+
For more info, see the documentation in those repos' READMEs.
152
167
153
168
### Other ways to contribute
154
169
155
170
There are a bunch of other ways you can contribute, especially if you don't
156
171
feel comfortable jumping straight into the large `rust-lang/rust` codebase.
157
172
158
-
The following tasks are doable without much background knowledge but are
159
-
incredibly helpful:
173
+
The following tasks are doable without much background knowledge but are incredibly helpful:
160
174
161
175
-[Writing documentation][wd]: if you are feeling a bit more intrepid, you could try
162
-
to read a part of the code and write doc comments for it. This will help you
163
-
to learn some part of the compiler while also producing a useful artifact!
176
+
to read a part of the code and write doc comments for it.
177
+
This will help you to learn some part of the compiler while also producing a useful artifact!
164
178
-[Triaging issues][triage]: categorizing, replicating, and minimizing issues is very helpful to the Rust maintainers.
165
179
-[Working groups][wg]: there are a bunch of working groups on a wide variety
166
180
of rust-related things.
167
181
- Answer questions on [users.rust-lang.org][users], or on [Stack Overflow][so].
168
182
- Participate in the [RFC process](https://github.com/rust-lang/rfcs).
169
183
- Find a [requested community library][community-library], build it, and publish
170
-
it to [Crates.io](http://crates.io). Easier said than done, but very, very
Now find the <libname>.ll under target/amdgcn-amd-amdhsa folder and copy it to a device.ll file (or adjust the file names below).
82
+
Now find the `<libname>.ll` under target/amdgcn-amd-amdhsa folder and copy it to a device.ll file (or adjust the file names below).
83
83
If you work on an NVIDIA or Intel gpu, please adjust the names acordingly and open an issue to share your results (either if you succeed or fail).
84
84
First we compile our .ll files (good for manual inspections) to .bc files and clean up leftover artifacts. The cleanup is important, otherwise caching might interfere on following runs.
0 commit comments