forked from rust-lang/rfcs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'master' of github.com:rust-lang/rfcs
- Loading branch information
1 parent
d8321d8
commit 7fc338e
Showing
5 changed files
with
313 additions
and
91 deletions.
There are no files selected for viewing
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
# RFC policy - the compiler | ||
|
||
We have not previously had an RFC system for compiler changes, so policy here is | ||
likely to change as we get the hang of things. We don't want to slow down most | ||
compiler development, but on the other hand we do want to do more design work | ||
ahead of time on large additions and refactorings. | ||
|
||
Compiler RFCs will be managed by the compiler sub-team, and tagged `T-compiler`. | ||
The compiler sub-team will do an initial triage of new PRs within a week of | ||
submission. The result of triage will either be that the PR is assigned to a | ||
member of the sub-team for shepherding, the PR is closed because the sub-team | ||
believe it should be done without an RFC, or closed because the sub-team feel it | ||
should clearly not be done and further discussion is not necessary. We'll follow | ||
the standard procedure for shepherding, final comment period, etc. | ||
|
||
Where there is significant design work for the implementation of a language | ||
feature, the preferred workflow is to submit two RFCs - one for the language | ||
design and one for the implementation design. The implementation RFC may be | ||
submitted later if there is scope for large changes to the language RFC. | ||
|
||
|
||
## Changes which need an RFC | ||
|
||
* Large refactorings or redesigns of the compiler | ||
* Changing the API presented to syntax extensions or other compiler plugins in | ||
non-trivial ways | ||
* Adding, removing, or changing a stable compiler flag | ||
* The implementation of new language features where there is significant change | ||
or addition to the compiler. There is obviously some room for interpretation | ||
about what consitutes a "significant" change and how much detail the | ||
implementation RFC needs. For guidance, [associated items](text/0195-associated-items.md) | ||
and [UFCS](text/0132-ufcs.md) would clearly need an implementation RFC, | ||
[type ascription](text/0803-type-ascription.md) and | ||
[lifetime elision](text/0141-lifetime-elision.md) would not. | ||
* Any other change which causes backwards incompatible changes to stable | ||
behaviour of the compiler, language, or libraries | ||
|
||
|
||
## Changes which don't need an RFC | ||
|
||
* Bug fixes, improved error messages, etc. | ||
* Minor refactoring/tidying up | ||
* Implmenting language features which have an accepted RFC, where the | ||
implementation does not significantly change the compiler or require | ||
significant new design work | ||
* Adding unstable API for tools (note that all compiler API is currently unstable) | ||
* Adding, removing, or changing an unstable compiler flag (if the compiler flag | ||
is widely used there should be at least some discussion on discuss, or an RFC | ||
in some cases) | ||
|
||
If in doubt it is probably best to just announce the change you want to make to | ||
the compiler subteam on discuss or IRC, and see if anyone feels it needs an RFC. |
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
# RFC policy - language design | ||
|
||
Pretty much every change to the language needs an RFC. | ||
|
||
Language RFCs are managed by the language sub-team, and tagged `T-lang`. The | ||
language sub-team will do an initial triage of new PRs within a week of | ||
submission. The result of triage will either be that the PR is assigned to a | ||
member of the sub-team for shepherding, the PR is closed as postponed because | ||
the subteam believe it might be a good idea, but is not currently aligned with | ||
Rust's priorities, or the PR is closed because the sub-team feel it should | ||
clearly not be done and further discussion is not necessary. In the latter two | ||
cases, the sub-team will give a detailed explanation. We'll follow the standard | ||
procedure for shepherding, final comment period, etc. | ||
|
||
|
||
## Amendments | ||
|
||
Sometimes in the implementation of an RFC, changes are required. In general | ||
these don't require an RFC as long as they are very minor and in the spirit of | ||
the accepted RFC (essentially bug fixes). In this case implementers should | ||
submit an RFC PR which amends the accepted RFC with the new details. Although | ||
the RFC repository is not intended as a reference manual, it is preferred that | ||
RFCs do reflect what was actually implemented. Amendment RFCs will go through | ||
the same process as regular RFCs, but should be less controversial and thus | ||
should move more quickly. | ||
|
||
When a change is more dramatic, it is better to create a new RFC. The RFC should | ||
be standalone and reference the original, rather than modifying the existing | ||
RFC. You should add a comment to the original RFC with referencing the new RFC | ||
as part of the PR. | ||
|
||
Obviously there is some scope for judgment here. As a guideline, if a change | ||
affects more than one part of the RFC (i.e., is a non-local change), affects the | ||
applicability of the RFC to its motivating use cases, or there are multiple | ||
possible new solutions, then the feature is probably not 'minor' and should get | ||
a new RFC. |
Oops, something went wrong.