HackMD
Stabilization report template
Feel free to put N/A if a question doesn't seem to apply.
What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.
Summarize the major parts of the implementation and provide links into the code (or to PRs)
An example for async closures: https://rustc-dev-guide.rust-lang.org/coroutine-closures.html
Summarize existing test coverage of this feature
What does the test coverage landscape for this feature look like?
- Positive/negative behavioral tests.
- Positive/negative interface tests (e.g. compiler cli interface).
- Maybe link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.).
- Are there any (intentional/unintentional) gaps in test coverage?
Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing.
Has a call-for-testing period been conducted? If so, what feedback was received?
What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
What FIXMEs are still in the code for that feature and why is it ok to leave them there?
What static checks are done that are needed to prevent undefined behavior?
- Start with tests -> reverse map them to the code in the compiler?
