profile
viewpoint

lalrpop/lalrpop 1301

LR(1) parser generator for Rust

graydon/bors 350

Integration robot for buildbot and github

brson/rust-sdl 167

SDL bindings for Rust

dslomov/typed-objects-es7 110

ES7 typed objects spec draft

nikomatsakis/borrowck 53

Modeling NLL and the Rust borrowck

nikomatsakis/bidir-type-infer 28

Implementing the type system described in the paper "Complete and Easy Bidirectional Type Inference" in Rust

jbclements/rust-redex 19

A Redex Model of Rust, or more specifically an encoding of Patina, the formal model for rust's type safety

nikomatsakis/ascii-canvas 13

simple canvas for drawing lines and styled text and emitting to the terminal

push eventnikomatsakis/project-staged-rfcs

Niko Matsakis

commit sha 79e7dea923b514ccb1decd724600f76673e45da3

Update pull_request_template.md

view details

push time in 7 hours

create barnchnikomatsakis/project-staged-rfcs

branch : nikomatsakis-patch-2

created branch time in 7 hours

push eventnikomatsakis/project-staged-rfcs

Niko Matsakis

commit sha 547153e6c969b553ba1db6305364cd563be9fb18

Create pull_request_template.md

view details

push time in 7 hours

create barnchnikomatsakis/project-staged-rfcs

branch : nikomatsakis-patch-1

created branch time in 7 hours

push eventnikomatsakis/project-staged-rfcs

Niko Matsakis

commit sha a4cc12b7bd33ab26c2216a3b8f551344102dc593

Create experiment.md

view details

push time in 7 hours

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha fc9de05ad7994694e5e1c08b601250e92d155c41

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in a day

pull request commentrust-lang/rust

remove trivial `mk_predicate`s

r=me pending perf results, though we should prob merge either way

lcnr

comment created time in 2 days

pull request commentrust-lang/rust

remove trivial `mk_predicate`s

@bors rollup=never

lcnr

comment created time in 2 days

pull request commentrust-lang/rust

remove trivial `mk_predicate`s

@bors try @rust-timer queue

lcnr

comment created time in 2 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 080b40b613185f9dc3bb2de5689ccc53762cf905

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 2 days

create barnchnikomatsakis/chalk-ndm

branch : recursive-solver-document

created branch time in 2 days

push eventrust-lang/chalk

Jack Huey

commit sha edd1d864da252549a0c1cfd35d73f14d37ffbc96

Add lifetime outlives

view details

Jack

commit sha cf0ce2d3d71d01391b9b39625c4b6dc4ad8440e2

Simplify

view details

Jack

commit sha 46658a6a29dc2bc5636a0a38cad8f8ff6de891ec

Add a LifetimeOutlives struct

view details

Jack

commit sha 887eae1ea420e7830b1b17e36ee43b7a1dd2c443

Add region constraints in recursive solver

view details

Niko Matsakis

commit sha ea1ca4ddc43abcfed77420f294a3713fac714e18

Merge pull request #451 from jackh726/lifetime_outlives Add lifetime outlives goal

view details

push time in 2 days

PR merged rust-lang/chalk

Add lifetime outlives goal

c.c. #435

I'm not sure if this is exactly the approach we want to take here, but I figured I would open this for comments at least

+154 -38

2 comments

15 changed files

jackh726

pr closed time in 2 days

pull request commentrust-lang/chalk

Add lifetime outlives goal

@jackh726

So, I think that your current branch is effectively "hard-coding" the AddRegionConstraint logic in some sense, by baking it into the "simplification" logic for handling domain goals (rather than adding a special sort of goal that is baked in, and then "converting" to that via a standard program clause).

I don't quite understand your point about having refactored the resolvent special handling, and I don't quite understand what you mean about not being able to modify unification, but I can maybe try to do the thing I was talking about and see what happens.

I think I still prefer to have a special goal like AddRegionConstraint (or maybe a built-in notion of Outlives) so that the solver never tries to "bake in" what a domain-goal means, but it's not a really big difference.

As for the interaction with higher-ranked, let's shelve it for now, I don't think it's relevant to this PR yet.

jackh726

comment created time in 2 days

Pull request review commentrust-lang/chalk

Add lifetime outlives goal

 impl<I: Interner, C: Context<I>> Forest<I, C> {                     &goal.b,                     &mut ex_clause,                 )?,-                GoalData::DomainGoal(domain_goal) => {-                    ex_clause-                        .subgoals-                        .push(Literal::Positive(InEnvironment::new(+                GoalData::DomainGoal(domain_goal) => match domain_goal {

it seems like this logic is missing from the recursive solver?

jackh726

comment created time in 2 days

Pull request review commentrust-lang/chalk

Add lifetime outlives goal

 impl<I: Interner, C: Context<I>> Forest<I, C> {                     &goal.b,                     &mut ex_clause,                 )?,-                GoalData::DomainGoal(domain_goal) => {-                    ex_clause-                        .subgoals-                        .push(Literal::Positive(InEnvironment::new(+                GoalData::DomainGoal(domain_goal) => match domain_goal {

I think you would add it here

https://github.com/rust-lang/chalk/blob/ffa2e515a4fac85f053dcbe6307d73ebc0e82043/chalk-solve/src/recursive/fulfill.rs#L174-L180

but it'd be nice to refactor the two solvers to share this logic.

jackh726

comment created time in 2 days

Pull request review commentrust-lang/chalk

Add lifetime outlives goal

 fn normalize_ambiguous() {         }     } }++#[test]+fn lifetime_outlives_constraints() {+    test! {+        program {+            trait Foo<'a, 'b> where 'a: 'b {}+            struct Bar {}++            impl<'a, 'b> Foo<'a, 'b> for Bar where 'a: 'b {}+        }++        goal {+            exists<'a, 'b> {+                Bar: Foo<'a, 'b>+            }+        } yields[SolverChoice::slg(10, None)] {

ah I guess that's why you have slg here

jackh726

comment created time in 2 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha fecd65dcbbd9ea91a437fde3cd61eeb9af89903f

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 2 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR+    * In earlier versions of this RFC, we made the MCP proposas be a PR against the lang-team repo that contained the proposal.+    * The idea here was that it would be useful to have the text of the proposal as something we can merge as "not accepted" in order to have a better record.+    * We ultimately moved to an issue for a few reasons:+        * YAGNI: The tooling and workflow seemed more esoteric. The idea of opening first to a "not accepted" directory and then merging just felt a bit "unexpected" and harder to explain and envision.+        * It is hard to collaborate actively on a PR; a hackmd or other such document is better for this purpose.

This may also be true for the compiler team :)

nikomatsakis

comment created time in 2 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR+    * In earlier versions of this RFC, we made the MCP proposas be a PR against the lang-team repo that contained the proposal.+    * The idea here was that it would be useful to have the text of the proposal as something we can merge as "not accepted" in order to have a better record.+    * We ultimately moved to an issue for a few reasons:+        * YAGNI: The tooling and workflow seemed more esoteric. The idea of opening first to a "not accepted" directory and then merging just felt a bit "unexpected" and harder to explain and envision.+        * It is hard to collaborate actively on a PR; a hackmd or other such document is better for this purpose.

So I've been giving this some thought (and we had some discussion on Zulip) and I think I've come to the conclusion that -- presuming we continue to use issues, which I still lean towards -- we should have people paste the full text of the proposal into the issue.

In this way, the closed issue still serves as a nice record of the proposal.

nikomatsakis

comment created time in 2 days

pull request commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

@bors r+

estebank

comment created time in 2 days

Pull request review commentrust-lang/chalk

Model function ABI in the Rust IR

 impl LowerFnDefn for FnDefn {          Ok(rust_ir::FnDefDatum {             id: fn_def_id,+            abi: ChalkFnAbi::Rust,

hmm, yeah, it seems like we need a way to test this, so I think you should add it, though I'd probably prefer

extern "C" fn() { ... }

notation to #[fn_abi(C)]. You can handle that by parsing a string literal and comparing it against known values...

Mcat12

comment created time in 2 days

pull request commentrust-lang/rfcs

Transition to rust-analyzer as our official LSP (Language Server Protocol) implementation

Huzzah! This RFC has been merged. You can follow along at the tracking issue that @matklad created rust-analyzer/rust-analyzer#4224.

nikomatsakis

comment created time in 2 days

issue commentrust-analyzer/rust-analyzer

Tracking issue fo RFC2912, transition to rust-analyzer as our official LSP

Huzzah! This RFC has been merged. You can follow along at the tracking issue that @matklad created rust-analyzer/rust-analyzer#4224.

matklad

comment created time in 2 days

PR closed rust-lang/rfcs

Transition to rust-analyzer as our official LSP (Language Server Protocol) implementation A-language-server T-core disposition-merge finished-final-comment-period

The RFC proposes a plan to adopt rust-analyzer as Rust's official LSP (Language Server Protocol) implementation. The transition to rust-analyzer will take place in a few stages:

  • Feedback -- encourage people to use rust-analyzer and report problems
  • Deprecation -- actively transition people from the RLS to rust-analyzer
  • Final transition -- stop supporting the older RLS

As detailed below, one major concern with rust-analyzer as it stands today is that it shares very little code with rustc. To avoid creating an unsustainable maintenance burden, this RFC extracting shared libraries that will be used by both rustc and rust-analyzer ("library-ification"), which should eventually lead to rustc and rust-analyzer being two front-ends over a shared codebase.

Rendered.

Summary comments

If you're just joining the conversation, this summary comment summarizes all the points raised before it, and is a good starting point.

Thanks

Thanks to @matklad who co-authored the RFC.

+0 -0

52 comments

0 changed file

nikomatsakis

pr closed time in 2 days

push eventnikomatsakis/rfcs

Ralf Jung

commit sha cbbd0ce236ca4bc086dbb271e548a55ab75dcfac

initial RFC for unsafe blocks in unsafe fn

view details

Ralf Jung

commit sha 51ca5b4133ecd0292de99a58866012d40c6a3224

C# has unsafe blocks

view details

Ralf Jung

commit sha 77a99924b5c518d4e9d0e865d8f3dbff18acbfd2

link to logical introduction/elimination

view details

Ralf Jung

commit sha aa85ef7acc3212066ec0360388d0a991849a5c64

this makes short unsafe fn less ergonomic

view details

Ralf Jung

commit sha 5d46a2d62ddfe9be1b3c9c1aec5bb514db3d313c

numbered steps for the action plan

view details

Ralf Jung

commit sha 5571c39ece6599b765436bcb0332bbfeb165ae7f

add clippy to action plan

view details

Ralf Jung

commit sha 2550a0b6ba7d875c9ebeeb2b8f7c622fef59f19a

2021 maybe

view details

Ralf Jung

commit sha 153d2866084f752fe4a97449523b4a011f77be4a

maybe we should employ cargo fix

view details

Ralf Jung

commit sha 8cb1b3f09dd8f567e9e5ae7759708280708061b8

more alternatives

view details

Amanieu d'Antras

commit sha 26f644b3d00930680c8ee5480b2def436f6542ac

Introduce the ASM project group

view details

Amanieu d'Antras

commit sha 9b40deca976315430996398c191ff2d08793d64b

Fix repo link

view details

Amanieu d'Antras

commit sha eaaead5463b0a2f4e330e2b70b6b114e87412edb

Remove scope limitation

view details

Ralf Jung

commit sha 949590b8afb8b703507f94cf3917cd13721edb46

improve motivation

view details

Ralf Jung

commit sha ec454f290548a469f2fabe03a0214f57b468904b

update plan to include the lint

view details

Ralf Jung

commit sha 1b3e1dddbc9e3703fd019ff28110ac0bcd515adc

mention that the lint name is not final yet

view details

Ralf Jung

commit sha 2e47c418373789b10603aaaa98057882ec8d6ee8

minor editing; unsafe_to_call alternative

view details

Ralf Jung

commit sha 814301e45efdec4b3279e54dd756564529f2effd

mention an alternative that avoids lint-on-lint dependencies

view details

Ralf Jung

commit sha 9838e5d9243ce38b74fc064009fa4b592d9a08f8

mention 'other opt-in switch' as unresolved question

view details

Niko Matsakis

commit sha ee4abcb352223fe893cf2f48f9be60a1f30cf0f1

major change proposal

view details

Niko Matsakis

commit sha c3ba0502e1b87b8da56d589f97f1dfbcc02815f7

Update text/0000-compiler-major-change-process.md Co-Authored-By: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com>

view details

push time in 2 days

push eventrust-lang/rfcs

Niko Matsakis

commit sha 55213ffb08181c1b5d09e6e5a88d7759df9532e5

first revision

view details

Niko Matsakis

commit sha e7a97134627fb9f49d82f88d079ed01f3f82b583

s/IDE/LSP implementation/ rust-analyzer is not, actually, an IDE

view details

Niko Matsakis

commit sha 8e6e0105ef650b64d21ee86251d0796e799ea194

Update text/0000-rust-analyzer.md Co-Authored-By: Who? Me?! <mark-i-m@users.noreply.github.com>

view details

Niko Matsakis

commit sha 0ed9fbd3dab982f823ef3f4bc8ad82280dcca1f7

Update text/0000-rust-analyzer.md Co-Authored-By: Who? Me?! <mark-i-m@users.noreply.github.com>

view details

Niko Matsakis

commit sha 264d37006122e80cdeb5510539efcdd405ceae53

clarify that support for other editors may come later

view details

Niko Matsakis

commit sha 707999b9466034c805918adafa563562823e5a18

Apply suggestions from code review Co-Authored-By: Martin Glagla <mglagla@users.noreply.github.com> Co-Authored-By: Jonas Platte <jplatte@users.noreply.github.com> Co-Authored-By: Clement Tsang <34804052+ClementTsang@users.noreply.github.com>

view details

Niko Matsakis

commit sha c7c3549908793463045dd379b83bb29f8b5f8fff

revert to the more elaborate deprecation/transition names (as they are used elsewhere)

view details

Niko Matsakis

commit sha 190ef52575f32dcd1bd9e1a3a52d9fa6c352ac2a

link to ocaml-lsp

view details

Niko Matsakis

commit sha a8ae4e28cccc98b749358a96559539de881463b7

Nit: adjust single/double quotes mismatch

view details

Niko Matsakis

commit sha 726b102f69ace76a5f0ecf1266990923ec3004b6

note intention to distribute through rustup and conform to LSP

view details

Niko Matsakis

commit sha c487320604b28e3e04a6202f623ddff6a64dd85f

document unstable extensions

view details

Niko Matsakis

commit sha 26e766e41f64cd08f0a862617a082a97291781c3

note feature parity alternative

view details

Niko Matsakis

commit sha ba27c4c027704c716fcc1f54be601939fdc29c57

RFC 2912 is "Transition to rust-analyzer as our official LSP"

view details

Niko Matsakis

commit sha b6fffdf18f8b867648de0d95657cc13a64cae4e2

update metadata

view details

push time in 2 days

pull request commentrust-lang/rfcs

Destructuring assignment

I'm nominating to check-in briefly in the upcoming meeting (though I'll send out some pings before-hand). I for one have oft wanted this, and given that @varkor and @fanzier have a draft implementation, I'd like to see it move forward (caveat: I've not read the RFC in detail or thought carefully about e.g. parser ambiguities, but I'm trusting that the thread would have uncovered such concerns already).

varkor

comment created time in 2 days

push eventrust-lang/rfcs

Senrelio

commit sha 6041dd9ff2ed97eff4e054117cc1581b8c45d8c1

Update 2394-async_await.md 'block_on' function might have been moved from futures module to futures::executor module. I wonder if the dependency used there should be state explicitly?

view details

Niko Matsakis

commit sha dc816b7eceaa386cc43816969d8973c67c7a2aaf

Merge pull request #2932 from Senrelio/patch-1 Update 2394-async_await.md

view details

push time in 2 days

PR merged rust-lang/rfcs

Update 2394-async_await.md

'block_on' function might have been moved from futures module to futures::executor module. I wonder if the dependency used there should be state explicitly?

+1 -1

4 comments

1 changed file

Senrelio

pr closed time in 2 days

pull request commentrust-lang/rfcs

Update 2394-async_await.md

I think we should merge it, though I agree that we don't have a general rule towards keeping RFCs fully up to date.

Senrelio

comment created time in 2 days

pull request commentrust-lang/rust

fix EncodeWithShorthand for Predicate

@bors r+ rollup=never

Seems unlikely this has a perf impact but worth being able to track it if so.

lcnr

comment created time in 2 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 8bdcb40849ec591720266d6a940f65856c506bd5

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 2 days

pull request commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

@XAMPPRocky

One thing that came to my mind while reading the RFC is what does the Major Change Process mean for lang PRs opened directly on rust-lang/rust?

Yeah, this is a good question. We had a similar question arise in the compiler team. Our conclusion there was that we can encourage the author to submit an MCP but (typically) leave the PR open, simply in a blocked state. It's also ok to close, but it often feels more polite to leave it open.

The idea in the compiler team at least was that this encouraged folks to write some docs and the high-level plan and to communicate that out to the wider team, which is difficult to do from a PR This stems in part from the observation that the primary role of MCPs on the compiler team is probably encouraging planning, documentation and communication, more so than regulating changes, although they do also serve that function. On the lang team, I think that regulating changes ("do we want this") is going to be a bigger part.

Have to think a bit about it, but it seems like encouraging folks to write-up an MCP if the change is "real enough" makes sense.

(Separately but relatedly, I'm wondering about stabilization reports-- we currently have folks write them up, but it's not well documented, I don't think there's a template, and I don't think we collect them anywhere. It'd be nice if we did.)

nikomatsakis

comment created time in 2 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha f6d9c4faa94fb084976606e4ecabac18aa01b8c6

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 2 days

pull request commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

I don't see any mention of what happens to RFCs without an MCP. i assume they are closed either automatically or manually, it would be nice to be explicit about it. Otherwise, the proposal looks great and I'm excited to see how it works in practice.

Ah, you don't mean "pre-existing RFCs" (which I did try to address) but rather "new RFCs introduced after we adopt this system"?

If so, yes, I plan to close them. I'll add a note about it, good catch.

nikomatsakis

comment created time in 2 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha c709398d363e8c05519cb3404b05373c56ee2719

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 3 days

pull request commentrust-lang/rust

Fix ICE with explicit late-bound lifetimes

@bors r+

doctorn

comment created time in 3 days

issue closedrust-lang/rust

Breaking Change in Vec::truncate drop order between 1.40 -> 1.41

Context: The commit that introduced the change. The PR for the commit

Minimal repro can be found in the commit and the PR. At work we have a private internal crate that depended on this drop ordering. As we had not run the beta train we did not catch it until attempting to upgrade our stable version of rust to 1.41.0. Now while the behavior of the drop order was unspecified it has been stabilized.

I'm sure we can find a workaround for this at work, but I'm filing this issue as it brings up some interesting questions that I don't know if the libs team has ever taken an official stance on.

If the observable behavior changes but isn't specified is this a breaking change? The API itself has not changed, but the drop order has changed. I'm of the opinion it is a breaking change even if it brings the API more in line with how slice drop order works, though talking to some friends they are of the opinion it is not a breaking change.

Anyways I wanted to file this issue to bring attention to this and maybe get a more clear ruling from the libs team on what they consider is and is not breaking change behavior. If more info is needed on why we needed this @estebank and I can probably give more specifics on this, though I don't think this is so much trying to fix a bug as it is determining whether a change should be reverted.

Thanks! 😄

closed time in 3 days

mgattozzi

issue commentrust-lang/rust

Breaking Change in Vec::truncate drop order between 1.40 -> 1.41

So...it's been 5 months here. I think it's unlikely that we're going to take any action to further change the drop order of Vec::truncate. Further, Vec's documentation does state:

Vec does not currently guarantee the order in which elements are dropped. The order has changed in the past and may change again.

Therefore, I'm going to close this issue. Thanks to @mgattozzi for raising it. Feel free to re-open if you think this is unjustified.

mgattozzi

comment created time in 3 days

Pull request review commentrust-lang/rust

`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc

 unsafe fn exchange_malloc(size: usize, align: usize) -> *mut u8 { // For example if `Box` is changed to  `struct Box<T: ?Sized, A: AllocRef>(Unique<T>, A)`, // this function has to be changed to `fn box_free<T: ?Sized, A: AllocRef>(Unique<T>, A)` as well. pub(crate) unsafe fn box_free<T: ?Sized>(ptr: Unique<T>) {-    let size = size_of_val(ptr.as_ref());-    let align = min_align_of_val(ptr.as_ref());-    let layout = Layout::from_size_align_unchecked(size, align);-    Global.dealloc(ptr.cast().into(), layout)+    unsafe {+        let size = size_of_val(ptr.as_ref());+        let align = min_align_of_val(ptr.as_ref());+        let layout = Layout::from_size_align_unchecked(size, align);+        Global.dealloc(ptr.cast().into(), layout)

ah maybe so

LeSeulArtichaut

comment created time in 3 days

issue commentrust-lang/rust

Consider deprecation of UB-happy `static mut`

What is the harm to putting it in core? Is it just a sense of bloat, or is there something else?

eddyb

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

Thanks @KodrAus -- that all sounded about right to me. One thing I was hoping to get is a few pointers to test cases that demonstrate this function working as expected (and ideally some notes on what they test).

For example, it seems like it'd be good to test that the type-id we get from const evauation is, in fact, equal to the runtime one. =)

KodrAus

comment created time in 3 days

issue commentrust-lang/rust

error: expected identifier when building time-macros-impl v0.1.1

If we were to revert the change, would that then "re-break" crates like syn? Or can they accommodate both forms now.

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc

 unsafe fn exchange_malloc(size: usize, align: usize) -> *mut u8 { // For example if `Box` is changed to  `struct Box<T: ?Sized, A: AllocRef>(Unique<T>, A)`, // this function has to be changed to `fn box_free<T: ?Sized, A: AllocRef>(Unique<T>, A)` as well. pub(crate) unsafe fn box_free<T: ?Sized>(ptr: Unique<T>) {-    let size = size_of_val(ptr.as_ref());-    let align = min_align_of_val(ptr.as_ref());-    let layout = Layout::from_size_align_unchecked(size, align);-    Global.dealloc(ptr.cast().into(), layout)+    unsafe {+        let size = size_of_val(ptr.as_ref());+        let align = min_align_of_val(ptr.as_ref());+        let layout = Layout::from_size_align_unchecked(size, align);+        Global.dealloc(ptr.cast().into(), layout)

this is probably the only unsafe thing? or else this + the last two lines

LeSeulArtichaut

comment created time in 3 days

Pull request review commentrust-lang/rust

`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc

 unsafe impl AllocRef for Global {         match placement {             ReallocPlacement::InPlace => Err(AllocErr),             ReallocPlacement::MayMove if new_size == 0 => {-                self.dealloc(ptr, layout);+                unsafe {+                    self.dealloc(ptr, layout);+                }                 Ok(MemoryBlock { ptr: layout.dangling(), size: 0 })             }             ReallocPlacement::MayMove => {                 // `realloc` probably checks for `new_size < size` or something similar.-                intrinsics::assume(new_size < size);-                let ptr = realloc(ptr.as_ptr(), layout, new_size);-                Ok(MemoryBlock { ptr: NonNull::new(ptr).ok_or(AllocErr)?, size: new_size })+                unsafe {+                    intrinsics::assume(new_size < size);+                    let ptr = realloc(ptr.as_ptr(), layout, new_size);

similarly here, is the only unsafe thing the realloc? (maybe also the assume?)

LeSeulArtichaut

comment created time in 3 days

Pull request review commentrust-lang/rust

`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc

 unsafe impl AllocRef for Global {         match placement {             ReallocPlacement::InPlace => Err(AllocErr),             ReallocPlacement::MayMove if layout.size() == 0 => {-                let new_layout = Layout::from_size_align_unchecked(new_size, layout.align());+                let new_layout =+                    unsafe { Layout::from_size_align_unchecked(new_size, layout.align()) };                 self.alloc(new_layout, init)             }             ReallocPlacement::MayMove => {                 // `realloc` probably checks for `new_size > size` or something similar.-                intrinsics::assume(new_size > size);-                let ptr = realloc(ptr.as_ptr(), layout, new_size);-                let memory =-                    MemoryBlock { ptr: NonNull::new(ptr).ok_or(AllocErr)?, size: new_size };-                init.init_offset(memory, size);-                Ok(memory)+                unsafe {

In this instance it might be nice to make the unsafe finer-grained?

LeSeulArtichaut

comment created time in 3 days

pull request commentrust-lang/rust

Add test to make sure -Wunused-crate-dependencies works with tests

Oh, I guess it was r? @petrochenkov :)

jsgf

comment created time in 3 days

pull request commentrust-lang/rust

Add test to make sure -Wunused-crate-dependencies works with tests

@bors delegate+

r=me once CI is happy

jsgf

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

 LL | fn b(v: &[u8]) -> Box<dyn Foo + 'static> { LL |     Box::new(v)    |     ^^^^^^^^^^^ lifetime `'static` required -error[E0621]: explicit lifetime required in the type of `v`-  --> $DIR/region-object-lifetime-in-coercion.rs:21:5+error: cannot infer an appropriate lifetime+  --> $DIR/region-object-lifetime-in-coercion.rs:20:14    |-LL | fn c(v: &[u8]) -> Box<dyn Foo> {-   |         ----- help: add explicit lifetime `'static` to the type of `v`: `&'static [u8]`-... LL |     Box::new(v)-   |     ^^^^^^^^^^^ lifetime `'static` required+   |     ---------^-+   |     |        |+   |     |        ...but this borrow...+   |     this is `'static`...+   |+note: ...can't outlive the anonymous lifetime #1 defined on the function body at 17:1+  --> $DIR/region-object-lifetime-in-coercion.rs:17:1+   |+LL | / fn c(v: &[u8]) -> Box<dyn Foo> {+LL | |     // same as previous case due to RFC 599+LL | |+LL | |     Box::new(v)+LL | | }+   | |_^+help: you can add a bound to the returned `dyn Trait` to make it last less than `'static` and match the anonymous lifetime #1 defined on the function body at 17:1+   |+LL | fn c(v: &[u8]) -> Box<dyn Foo + '_> {+   |                               ^^^^

you can leave out the "as shown", I'm not sure how implicit it really is, but I can believe it

estebank

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

-error[E0621]: explicit lifetime required in the type of `value`-  --> $DIR/issue-16922.rs:4:5+error: cannot infer an appropriate lifetime+  --> $DIR/issue-16922.rs:4:14    |-LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> {-   |                       -- help: add explicit lifetime `'static` to the type of `value`: `&'static T` LL |     Box::new(value) as Box<dyn Any>-   |     ^^^^^^^^^^^^^^^ lifetime `'static` required+   |     ---------^^^^^-+   |     |        |+   |     |        ...but this borrow...+   |     this evaluates to the `'static` lifetime...+   |+note: ...can't outlive the anonymous lifetime #1 defined on the function body at 3:1+  --> $DIR/issue-16922.rs:3:1+   |+LL | / fn foo<T: Any>(value: &T) -> Box<dyn Any> {+LL | |     Box::new(value) as Box<dyn Any>+LL | |+LL | | }+   | |_^+help: you can add a bound to the returned `dyn Trait` to make it last less than `'static` and match the anonymous lifetime #1 defined on the function body at 3:1

Yeah, I like this better.

estebank

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

-error[E0621]: explicit lifetime required in the type of `value`-  --> $DIR/issue-16922.rs:4:5+error: cannot infer an appropriate lifetime+  --> $DIR/issue-16922.rs:4:14    |-LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> {-   |                       -- help: add explicit lifetime `'static` to the type of `value`: `&'static T` LL |     Box::new(value) as Box<dyn Any>-   |     ^^^^^^^^^^^^^^^ lifetime `'static` required+   |     ---------^^^^^-+   |     |        |+   |     |        ...but this borrow...+   |     this evaluates to the `'static` lifetime...

it does give more information

estebank

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

-error[E0621]: explicit lifetime required in the type of `value`-  --> $DIR/issue-16922.rs:4:5+error: cannot infer an appropriate lifetime+  --> $DIR/issue-16922.rs:4:14    |-LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> {-   |                       -- help: add explicit lifetime `'static` to the type of `value`: `&'static T` LL |     Box::new(value) as Box<dyn Any>-   |     ^^^^^^^^^^^^^^^ lifetime `'static` required+   |     ---------^^^^^-+   |     |        |+   |     |        ...but this borrow...+   |     this evaluates to the `'static` lifetime...

this looks good too, though it still has the "jumbled" look I was hoping to avoid

estebank

comment created time in 3 days

issue commentrust-lang/compiler-team

make an ICE-breaker group for windows

Branch with rustc-dev-guide additions https://github.com/nikomatsakis/rustc-guide/tree/notification-groups

nikomatsakis

comment created time in 3 days

push eventnikomatsakis/rustc-dev-guide

Niko Matsakis

commit sha 7afd8d33f25f04a01de23f2a98b54ed6071658f1

add windows notification group

view details

Niko Matsakis

commit sha b15497d63b8103463056c99f152894fbfdec241d

rebrand LLVM ICE-breakers as a "notification group"

view details

push time in 3 days

create barnchnikomatsakis/rustc-guide

branch : notification-groups

created branch time in 3 days

pull request commentrust-lang/team

Add wg-windows

@spastorino CI is unhappy?

spastorino

comment created time in 3 days

issue commentrust-lang/compiler-team

make an ICE-breaker group for windows

Drafting blog post here: https://hackmd.io/3oMWDAyGT8-GxV5p9nLRnw

nikomatsakis

comment created time in 3 days

pull request commentrust-lang/rust

Fix ICE with explicit late-bound lifetimes

So I guess r=me with comment applied

doctorn

comment created time in 3 days

Pull request review commentrust-lang/rust

Fix ICE with explicit late-bound lifetimes

+// run-pass++#![allow(unused)]++struct S;++impl S {+    fn func<'a, U>(&'a self) -> U {+        todo!()+    }+}++fn dont_crash<'a, U>() -> U {+    S.func::<'a, U>()+    //~^ WARN cannot specify lifetime arguments explicitly+    //~| WARN this was previously accepted+}

Those tests look pretty good. I guess they don't cover lifetimes + types intermixed. But I'm satisfied.

doctorn

comment created time in 3 days

pull request commentrust-lang/rust

Warn about unused captured variables

@bors delegate+

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl<'a, 'tcx> Liveness<'a, 'tcx> {         self.rwu_table.assign_unpacked(idx, rwu);     } -    fn compute(&mut self, body: &hir::Expr<'_>) -> LiveNode {-        debug!("compute: using id for body, {:?}", body);+    fn compute(+        &mut self,+        fk: FnKind<'_>,+        body: &hir::Body<'_>,+        span: Span,+        id: hir::HirId,+    ) -> LiveNode {+        debug!("compute: using id for body, {:?}", body.value);++        let mut only_by_ref_upvars = true;+        if let Some(upvars) = self.ir.tcx.upvars_mentioned(self.ir.body_owner) {+            for (&var_hir_id, upvar) in upvars.iter().rev() {+                let upvar_id = ty::UpvarId {+                    var_path: ty::UpvarPath { hir_id: var_hir_id },+                    closure_expr_id: self.ir.body_owner.expect_local(),+                };+                match self.tables.upvar_capture(upvar_id) {+                    ty::UpvarCapture::ByRef(_) => {+                        let var = self.variable(var_hir_id, upvar.span);+                        self.acc(self.s.exit_ln, var, ACC_READ | ACC_USE);+                    }+                    ty::UpvarCapture::ByValue => {+                        only_by_ref_upvars = false;+                    }+                }+            }+        } -        // the fallthrough exit is only for those cases where we do not-        // explicitly return:-        let s = self.s;-        self.init_from_succ(s.fallthrough_ln, s.exit_ln);-        self.acc(s.fallthrough_ln, s.clean_exit_var, ACC_READ);+        let succ = self.propagate_through_expr(&body.value, self.s.exit_ln); -        let entry_ln = self.propagate_through_expr(body, s.fallthrough_ln);+        // When computing the liveness for captured variables we take into+        // account how variable is captured (ByRef vs ByValue) and what is the+        // closure kind (Generator / FnOnce vs Fn / FnMut).+        //+        // Variables captured by reference are assumed to be used on the exit+        // from the closure.+        //+        // In FnOnce closures, variables captured by value are known to be dead+        // on exit since it is impossible to invoke the closure again.+        //+        // In Fn / FnMut closures, variables captured by value are live on exit+        // if they are live on the entry to the closure, since only the closure+        // itself can access them on subsequent invocations.

(maybe mention it in the comment)

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl<'a, 'tcx> Liveness<'a, 'tcx> {         self.rwu_table.assign_unpacked(idx, rwu);     } -    fn compute(&mut self, body: &hir::Expr<'_>) -> LiveNode {-        debug!("compute: using id for body, {:?}", body);+    fn compute(+        &mut self,+        fk: FnKind<'_>,+        body: &hir::Body<'_>,+        span: Span,+        id: hir::HirId,+    ) -> LiveNode {+        debug!("compute: using id for body, {:?}", body.value);++        let mut only_by_ref_upvars = true;+        if let Some(upvars) = self.ir.tcx.upvars_mentioned(self.ir.body_owner) {+            for (&var_hir_id, upvar) in upvars.iter().rev() {+                let upvar_id = ty::UpvarId {+                    var_path: ty::UpvarPath { hir_id: var_hir_id },+                    closure_expr_id: self.ir.body_owner.expect_local(),+                };+                match self.tables.upvar_capture(upvar_id) {+                    ty::UpvarCapture::ByRef(_) => {+                        let var = self.variable(var_hir_id, upvar.span);+                        self.acc(self.s.exit_ln, var, ACC_READ | ACC_USE);+                    }+                    ty::UpvarCapture::ByValue => {+                        only_by_ref_upvars = false;+                    }+                }+            }+        } -        // the fallthrough exit is only for those cases where we do not-        // explicitly return:-        let s = self.s;-        self.init_from_succ(s.fallthrough_ln, s.exit_ln);-        self.acc(s.fallthrough_ln, s.clean_exit_var, ACC_READ);+        let succ = self.propagate_through_expr(&body.value, self.s.exit_ln); -        let entry_ln = self.propagate_through_expr(body, s.fallthrough_ln);+        // When computing the liveness for captured variables we take into+        // account how variable is captured (ByRef vs ByValue) and what is the+        // closure kind (Generator / FnOnce vs Fn / FnMut).

this comment captures some of the points I raised above, it just came later so I wouldn't have seen it yet while reading the code

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl<'a, 'tcx> Liveness<'a, 'tcx> {         self.rwu_table.assign_unpacked(idx, rwu);     } -    fn compute(&mut self, body: &hir::Expr<'_>) -> LiveNode {-        debug!("compute: using id for body, {:?}", body);+    fn compute(+        &mut self,+        fk: FnKind<'_>,+        body: &hir::Body<'_>,+        span: Span,+        id: hir::HirId,+    ) -> LiveNode {+        debug!("compute: using id for body, {:?}", body.value);++        let mut only_by_ref_upvars = true;+        if let Some(upvars) = self.ir.tcx.upvars_mentioned(self.ir.body_owner) {+            for (&var_hir_id, upvar) in upvars.iter().rev() {+                let upvar_id = ty::UpvarId {+                    var_path: ty::UpvarPath { hir_id: var_hir_id },+                    closure_expr_id: self.ir.body_owner.expect_local(),+                };+                match self.tables.upvar_capture(upvar_id) {+                    ty::UpvarCapture::ByRef(_) => {+                        let var = self.variable(var_hir_id, upvar.span);+                        self.acc(self.s.exit_ln, var, ACC_READ | ACC_USE);+                    }+                    ty::UpvarCapture::ByValue => {+                        only_by_ref_upvars = false;+                    }+                }+            }+        } -        // the fallthrough exit is only for those cases where we do not-        // explicitly return:-        let s = self.s;-        self.init_from_succ(s.fallthrough_ln, s.exit_ln);-        self.acc(s.fallthrough_ln, s.clean_exit_var, ACC_READ);+        let succ = self.propagate_through_expr(&body.value, self.s.exit_ln); -        let entry_ln = self.propagate_through_expr(body, s.fallthrough_ln);+        // When computing the liveness for captured variables we take into+        // account how variable is captured (ByRef vs ByValue) and what is the+        // closure kind (Generator / FnOnce vs Fn / FnMut).+        //+        // Variables captured by reference are assumed to be used on the exit+        // from the closure.+        //+        // In FnOnce closures, variables captured by value are known to be dead+        // on exit since it is impossible to invoke the closure again.+        //+        // In Fn / FnMut closures, variables captured by value are live on exit+        // if they are live on the entry to the closure, since only the closure+        // itself can access them on subsequent invocations.

where does this logic get setup, though?

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl<'a, 'tcx> Liveness<'a, 'tcx> {         // - exit_ln represents the end of the fn, either by return or panic         // - implicit_ret_var is a pseudo-variable that represents

pre-existing, I guess, but these comments seem out of date

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl RWUTable {  #[derive(Copy, Clone)] struct Specials {

Pre-existing, but if we're going to be extending this code, can we add a doc-comment explaining what a "special" is.

tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl<'a, 'tcx> Liveness<'a, 'tcx> {         self.rwu_table.assign_unpacked(idx, rwu);     } -    fn compute(&mut self, body: &hir::Expr<'_>) -> LiveNode {-        debug!("compute: using id for body, {:?}", body);+    fn compute(+        &mut self,+        fk: FnKind<'_>,+        body: &hir::Body<'_>,+        span: Span,+        id: hir::HirId,+    ) -> LiveNode {+        debug!("compute: using id for body, {:?}", body.value);++        let mut only_by_ref_upvars = true;+        if let Some(upvars) = self.ir.tcx.upvars_mentioned(self.ir.body_owner) {+            for (&var_hir_id, upvar) in upvars.iter().rev() {+                let upvar_id = ty::UpvarId {+                    var_path: ty::UpvarPath { hir_id: var_hir_id },+                    closure_expr_id: self.ir.body_owner.expect_local(),+                };+                match self.tables.upvar_capture(upvar_id) {+                    ty::UpvarCapture::ByRef(_) => {+                        let var = self.variable(var_hir_id, upvar.span);+                        self.acc(self.s.exit_ln, var, ACC_READ | ACC_USE);+                    }+                    ty::UpvarCapture::ByValue => {+                        only_by_ref_upvars = false;+                    }+                }+            }+        } -        // the fallthrough exit is only for those cases where we do not-        // explicitly return:-        let s = self.s;-        self.init_from_succ(s.fallthrough_ln, s.exit_ln);-        self.acc(s.fallthrough_ln, s.clean_exit_var, ACC_READ);+        let succ = self.propagate_through_expr(&body.value, self.s.exit_ln); -        let entry_ln = self.propagate_through_expr(body, s.fallthrough_ln);+        // When computing the liveness for captured variables we take into+        // account how variable is captured (ByRef vs ByValue) and what is the+        // closure kind (Generator / FnOnce vs Fn / FnMut).+        //+        // Variables captured by reference are assumed to be used on the exit+        // from the closure.+        //+        // In FnOnce closures, variables captured by value are known to be dead+        // on exit since it is impossible to invoke the closure again.+        //+        // In Fn / FnMut closures, variables captured by value are live on exit+        // if they are live on the entry to the closure, since only the closure+        // itself can access them on subsequent invocations.++        match fk {+            FnKind::Method(..) | FnKind::ItemFn(..) => return succ,+            FnKind::Closure(..) if only_by_ref_upvars => return succ,+            FnKind::Closure(..) => {}+        } -        // hack to skip the loop unless debug! is enabled:-        debug!(-            "^^ liveness computation results for body {} (entry={:?})",-            {-                for ln_idx in 0..self.ir.num_live_nodes {-                    debug!("{:?}", self.ln_str(LiveNode(ln_idx as u32)));-                }-                body.hir_id+        let ty = self.tables.node_type(id);+        match ty.kind {+            ty::Closure(_def_id, substs) => match substs.as_closure().kind() {+                ty::ClosureKind::Fn => {}+                ty::ClosureKind::FnMut => {}+                ty::ClosureKind::FnOnce => return succ,             },-            entry_ln-        );+            ty::Generator(..) => return succ,+            _ => {+                span_bug!(span, "type of closure expr {:?} is not a closure {:?}", id, ty,);+            }+        };++        self.init_from_succ(self.s.entry_ln, succ);+        for param in body.params {+            param.pat.each_binding(|_bm, hir_id, _x, ident| {+                let var = self.variable(hir_id, ident.span);+                self.define(self.s.entry_ln, var);+            })

can't we make this more dry by doing something like

let mut first_merge = true;
loop {
    self.init_from_succ(self.s.entry_ln, succ);
    for param in body.params {
            param.pat.each_binding(|_bm, hir_id, _x, ident| {
                let var = self.variable(hir_id, ident.span);
                self.define(self.s.entry_ln, var);
    })

    if !self.merge_from_succ(...) { break; }
    first_merge = false;
}
tmiasko

comment created time in 3 days

Pull request review commentrust-lang/rust

Warn about unused captured variables

 impl<'a, 'tcx> Liveness<'a, 'tcx> {         self.rwu_table.assign_unpacked(idx, rwu);     } -    fn compute(&mut self, body: &hir::Expr<'_>) -> LiveNode {-        debug!("compute: using id for body, {:?}", body);+    fn compute(+        &mut self,+        fk: FnKind<'_>,+        body: &hir::Body<'_>,+        span: Span,+        id: hir::HirId,+    ) -> LiveNode {+        debug!("compute: using id for body, {:?}", body.value);++        let mut only_by_ref_upvars = true;

Comment here would be nice --

  • why do we care if we only have by-ref upvars?
  • what is the role of the self.acc below (presumably so that we assume that by-ref upvars are used after the closure completes)
tmiasko

comment created time in 3 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 74620a7be1ef10334761e16df553c4253582841f

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 3 days

issue commentrust-lang/rust

Properly handle feature-gated lints

This implementation plan looks good to me -- if you think @LeSeulArtichaut that you'd like to mentor the issue, maybe tag it with E-easy and E-mentor! I'd probably extend the description above with

  • some links into the code to help people find the functions in question
  • a reference to your existing hard-coded support for unsafe_op_in_unsafe_fn lint, which I think is basically the model that we want to follow.
LeSeulArtichaut

comment created time in 3 days

pull request commentrust-lang/rust

Implement RFC 2585: unsafe blocks in unsafe fn

@bors r+

Thanks for seeing this through, @LeSeulArtichaut! I'll check out https://github.com/rust-lang/rust/issues/72694

LeSeulArtichaut

comment created time in 3 days

push eventLeSeulArtichaut/rust

Niko Matsakis

commit sha 0e3b31c641217542f02b40527b0d299d9534b920

Update src/librustdoc/core.rs

view details

push time in 3 days

Pull request review commentrust-lang/rust

Implement RFC 2585: unsafe blocks in unsafe fn

 where {     let warnings_lint_name = lint::builtin::WARNINGS.name; +    // Whitelist feature-gated lints to avoid feature errors when trying to+    // allow all lints.+    // FIXME(LeSeulArtichaut): handle feature-gated lints properly.
    // FIXME(#72694): handle feature-gated lints properly.
LeSeulArtichaut

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

-error[E0621]: explicit lifetime required in the type of `value`-  --> $DIR/issue-16922.rs:4:5+error: cannot infer an appropriate lifetime+  --> $DIR/issue-16922.rs:4:14    |-LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> {-   |                       -- help: add explicit lifetime `'static` to the type of `value`: `&'static T` LL |     Box::new(value) as Box<dyn Any>-   |     ^^^^^^^^^^^^^^^ lifetime `'static` required+   |     ---------^^^^^-+   |     |        |+   |     |        ...but this borrow...+   |     this evaluates to the `'static` lifetime...

Do you think we could print this?

error[E0621]: non-static reference captured in `dyn Any` type without explicit bound
  --> $DIR/issue-16922.rs:4:5
   |
LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> {
   |                       -- data with this lifetime...
LL |     Box::new(value) as Box<dyn Any>
   |     ^^^^^^^^^^^^^^^ is captured in a `dyn Any` type here with the default `'static` bound
help: for a `dyn` type to capture a non-static reference, it needs an explicit bound, as shown
   |
LL | fn foo<T: Any>(value: &T) -> Box<dyn Any + '_> {
   |                             

It seems like we might know everything we need to know to "special case" this scenario, no?

estebank

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

 LL | fn b(v: &[u8]) -> Box<dyn Foo + 'static> { LL |     Box::new(v)    |     ^^^^^^^^^^^ lifetime `'static` required -error[E0621]: explicit lifetime required in the type of `v`-  --> $DIR/region-object-lifetime-in-coercion.rs:21:5+error: cannot infer an appropriate lifetime+  --> $DIR/region-object-lifetime-in-coercion.rs:20:14    |-LL | fn c(v: &[u8]) -> Box<dyn Foo> {-   |         ----- help: add explicit lifetime `'static` to the type of `v`: `&'static [u8]`-... LL |     Box::new(v)-   |     ^^^^^^^^^^^ lifetime `'static` required+   |     ---------^-+   |     |        |+   |     |        ...but this borrow...+   |     this is `'static`...+   |+note: ...can't outlive the anonymous lifetime #1 defined on the function body at 17:1+  --> $DIR/region-object-lifetime-in-coercion.rs:17:1+   |+LL | / fn c(v: &[u8]) -> Box<dyn Foo> {+LL | |     // same as previous case due to RFC 599+LL | |+LL | |     Box::new(v)+LL | | }+   | |_^+help: you can add a bound to the returned `dyn Trait` to make it last less than `'static` and match the anonymous lifetime #1 defined on the function body at 17:1+   |+LL | fn c(v: &[u8]) -> Box<dyn Foo + '_> {+   |                               ^^^^

I might say

help: to permit non-static references in a dyn Trait value, you need to add an explicit bound, as shown

or

help: consider adding an explicit bound to the dyn Trait as shown, which is used to declare that the dyn Trait may capture non-static references

estebank

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

 impl<'a, 'tcx> InferCtxt<'a, 'tcx> {             }         } +        let new_binding_suggestion =+            |err: &mut DiagnosticBuilder<'tcx>,+             type_param_span: Option<(Span, bool, bool)>,+             bound_kind: GenericKind<'tcx>| {+                let msg = "consider introducing an explicit lifetime bound to unify the type \

I prefer that, yes.

estebank

comment created time in 3 days

Pull request review commentrust-lang/rust

Account for missing lifetime in opaque and trait object return types

+error[E0261]: use of undeclared lifetime name `'a`+  --> $DIR/missing-lifetimes-in-signature.rs:37:11+   |+LL | fn baz<G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+   |        -  ^^ undeclared lifetime+   |        |+   |        help: consider introducing lifetime `'a` here: `'a,`++error: cannot infer an appropriate lifetime+  --> $DIR/missing-lifetimes-in-signature.rs:19:5+   |+LL |   fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce()+   |                                       ------------- this evaluates to the `'static` lifetime...+...+LL | /     move || {+LL | |         *dest = g.get();+LL | |     }+   | |_____^ ...but this borrow...+   |+note: ...can't outlive the anonymous lifetime #1 defined on the function body at 15:1+  --> $DIR/missing-lifetimes-in-signature.rs:15:1+   |+LL | / fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce()+LL | | where+LL | |     G: Get<T>+LL | | {+...  |+LL | |     }+LL | | }+   | |_^+help: you can add a bound to the returned `impl Trait` to make it last less than `'static` and match the anonymous lifetime #1 defined on the function body at 15:1+   |+LL | fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+   |                                                   ^^^^++error[E0311]: the parameter type `G` may not live long enough+  --> $DIR/missing-lifetimes-in-signature.rs:25:37+   |+LL | fn bar<G, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+   |                                     ^^^^^^^^^^^^^^^^^^+   |+note: the parameter type `G` must be valid for the anonymous lifetime #1 defined on the function body at 25:1...+  --> $DIR/missing-lifetimes-in-signature.rs:25:1+   |+LL | / fn bar<G, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+LL | |+LL | | where+LL | |     G: Get<T>+...  |+LL | |     }+LL | | }+   | |_^+note: ...so that the type `[closure@$DIR/missing-lifetimes-in-signature.rs:30:5: 32:6 g:G, dest:&mut T]` will meet its required lifetime bounds+  --> $DIR/missing-lifetimes-in-signature.rs:25:37+   |+LL | fn bar<G, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+   |                                     ^^^^^^^^^^^^^^^^^^+help: consider introducing an explicit lifetime bound to unify the type parameter and the output+   |+LL | fn bar<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a+   |        ^^^^^                                                   ^^^^++error[E0311]: the parameter type `G` may not live long enough+  --> $DIR/missing-lifetimes-in-signature.rs:47:45+   |+LL | fn qux<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+   |                                             ^^^^^^^^^^^^^^^^^^+   |+note: the parameter type `G` must be valid for the anonymous lifetime #1 defined on the function body at 47:1...+  --> $DIR/missing-lifetimes-in-signature.rs:47:1+   |+LL | / fn qux<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+LL | |+LL | | where+LL | |     G: Get<T>+...  |+LL | |     }+LL | | }+   | |_^+note: ...so that the type `[closure@$DIR/missing-lifetimes-in-signature.rs:52:5: 54:6 g:G, dest:&mut T]` will meet its required lifetime bounds+  --> $DIR/missing-lifetimes-in-signature.rs:47:45+   |+LL | fn qux<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_+   |                                             ^^^^^^^^^^^^^^^^^^+help: consider introducing an explicit lifetime bound to unify the type parameter and the output+   |+LL | fn qux<'b, 'a, G: 'b + 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'b+   |        ^^^     ^^^^^^^                                                  ^^^^

I guess it feels like this suggestion will not really help the user know what's going on -- they have to apply it and then maybe they'll understand -- but maybe that's the best we can do.

estebank

comment created time in 3 days

pull request commentrust-lang/rust

Remove legacy InnoSetup GUI installer

@retep998 was that a "r+"?

ChrisDenton

comment created time in 3 days

pull request commentrust-lang/rust

split select into submodules

@bors r+

lcnr

comment created time in 3 days

PR closed rust-lang/rust

Remove noisy suggestion of hash_map S-waiting-on-review

Removed import suggestion of std::collections::hash_map::HashMap #72642

+0 -0

5 comments

0 changed file

ayushmishra2005

pr closed time in 3 days

pull request commentrust-lang/rust

Remove noisy suggestion of hash_map

Since this PR is presently empty, I'm going to close it for now -- @ayushmishra2005 feel free to re-open when it's ready for review :)

ayushmishra2005

comment created time in 3 days

pull request commentrust-lang/rust

expand unaligned_references test

@bors r+ rollup

RalfJung

comment created time in 3 days

pull request commentrust-lang/rust

Fix incorrect comment in generator test

@bors r+ rollup

jonas-schievink

comment created time in 3 days

pull request commentrust-lang/rust

Make remote-test-client and remote-test-server compatible with windows

Good example where I would want to ping the windows group, once it's setup. For now, cc @retep998 and @rylev to check briefly the assertions about PATH and LD_LIBRARY_PATH above.

r=me otherwise.

seritools

comment created time in 3 days

pull request commentrust-lang/rust

Remove rustc-ux-guidelines

@bors r+ rollup

ehuss

comment created time in 3 days

push eventrust-lang/chalk

Jack

commit sha 0333528cd89d8f1ba70d55ff7b635a1f8e3e16dc

Add function def clauses

view details

Jack

commit sha c8f342bf5e48051333d0b2c7fab81347fc21c474

FnDefs impl Fn

view details

Niko Matsakis

commit sha 52a353064d6222f55307ca603c33a17ef4428f81

Merge pull request #477 from jackh726/fn_def Add function def clauses

view details

push time in 3 days

PR merged rust-lang/chalk

Add function def clauses

Missed in https://github.com/rust-lang/chalk/pull/449

Also Sized test for Never

+86 -0

0 comment

5 changed files

jackh726

pr closed time in 3 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.

Yes, I presume we would.

nikomatsakis

comment created time in 3 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR+    * In earlier versions of this RFC, we made the MCP proposas be a PR against the lang-team repo that contained the proposal.+    * The idea here was that it would be useful to have the text of the proposal as something we can merge as "not accepted" in order to have a better record.+    * We ultimately moved to an issue for a few reasons:+        * YAGNI: The tooling and workflow seemed more esoteric. The idea of opening first to a "not accepted" directory and then merging just felt a bit "unexpected" and harder to explain and envision.+        * It is hard to collaborate actively on a PR; a hackmd or other such document is better for this purpose.

I think my assumption was that -- much like compiler-team MCPs -- the longer text is often included "out of line", in a hackmd or gist.

nikomatsakis

comment created time in 3 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR

(That said, I will say that I'm a bit nervous about lang-team discussions moving too much to Zulip, because I fear it will stress the moderation story there.)

nikomatsakis

comment created time in 3 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR

In terms of "who should be the participants", your comments teased out something. I am thinking that perhaps the idea of the MCP should be more about seeking feedback from the lang-team (or perhaps other intersecting teams, key stakeholders, etc) than feedback from the wider community. I imagine the "wider community" feedback probably happening earlier, on internals or elsewhere, and it would be summarized as part of the MCP.

nikomatsakis

comment created time in 3 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR

But to reply to your original point, I also generally find it quite hard to follow PRs discussions, with their combination of "in-line comments" and "main-line comments" and so forth. There isn't really a perfect setup here.

nikomatsakis

comment created time in 3 days

Pull request review commentrust-lang/rfcs

add lang-team Major Change Proposals as a "pre-RFC" step

+- Feature Name: N/A+- Start Date: 2020-05-27+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Introduce a new step, a **major change proposal** (MCP), that is taken before an RFC is created. +    * **Major change proposals** are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.+    * A Zulip topic is also created to discuss the proposal.+* MCPs can be resolve in a few ways:+    * If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.+    * If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.+    * Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.+* To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and publicly communicate)+    * Active project groups, grouped by liasion+    * Topics of interest that each member may wish to pursue+    * A [design notes] section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.++[design notes]: https://lang-team.rust-lang.org/design_notes.html+[project group]: https://github.com/rust-lang/rfcs/pull/2856++# Motivation+[motivation]: #motivation++The RFC system is one of Rust's great strengths, but we have found over time that there are also some shortcomings. The hope is that the "proposal" process will allow us to better focus our energies and create a more collaborative environment. Some of the benefits we foresee are as follows.++## More collaboration throughout the design process++Many people have reported that they have ideas that they would like to pursue, but that they find the RFC process intimidating. For example, they may lack the detailed knowledge of Rust required to complete the drafting of the RFC. ++Under the proposal system, people are able to bring ideas at an early stage and get feedback. If the idea is something we'd like to see happen, then a group of people can gather to push the RFC through to completion. The lang-team liaison can provide suggestions and keep the rest of the lang-team updated, so that if there are concerns, they are raised early.++Furthermore, we hope that project groups will help to shift the focus and way that design iteration happens, so that contentious issues can be discussed and settled in the group. RFC threads will be shorter-lived and used more to gather feedback and points of concern that can then be ironed out within the group and the greater team. (Note that, while a project group is driving the design, the team members are the ones making the ultimate decision.)++## More focus on RFCs that reflect current priorities++The RFC repository currently contains far too many RFCs for anyone to keep up with -- especially members of the lang-team. Some of these RFCs are unlikely to be accepted, either because the ideas are too early stage, or because they don't align well with the project's current goals. Other RFCs may be very solid indeed, but they can be lost in the noise. ++We expect that after this change, the only RFCs that will be open are those that have already seen iteration in a project group, with the aid of a project liaison and general approval of the team. This makes the RFC repository a good place to monitor for ideas that have traction.++Meanwhile, the lang-team proposals will still contain quite a mix of ideas. However, unlike the RFC repository, we do not intend to allow proposals to stay open indefinitely. Proposals that do not receive a liaison or have active discussion will be closed, so that the issue list remains a good indication of ideas that are under active consideration.++## More staging of discussion++Building on the previous point, we believe that this new process will allow us to better separate the different "stages" of the design and implementation process:++* **Very early design discussion** starts on internals or other spaces, as today.+* **Promising ideas** can be formed into a proposal and discussed with the lang-team on Zulip.+* For ideas that are accped, **design iteration and RFC authorship** takes place in the [project group], typically on Zulip or in lang team design meetings.+* Finally, **polished designs** are brought to the RFC repository for feedback.++## Swifter resolution of RFCs, with design iteration taking place in project groups++Because RFCs will be the end result of more discussion, we can expect to resolve them faster. If the discussion uncovers critical flaws or new considerations, the RFC may be withdrawn and edited, and a new RFC posted instead. This can also happen if there is simply a lot of feedback, even if the design doesn't change -- in those cases, the new RFC will be updated to include a summary of the major points as well as responses to them. When working on amended RFCs, we can focus the discussion on the oustanding questions and avoid rehashing oldr debates.++This should help with the problem that longer RFCs threads can be quite hard to follow. This is compounded by the fact that the RFC evolves over the course of the discussion, sometimes changing dramatically. Getting "up to speed" on the state of an RFC thread involves reading a mix of stale comments on older drafts that have long since been addressed, thoughts on motivation, details of the design, and other things, and trying to sort them into an order.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Hello! If you would like propose a change to the Rust language, you've come to the right place. The process can be summarized as follows (but check out the [flowchart] for a graphical version):++* Open a **major change proposal** (MCP) issue on the lang-team repository+    * The issue should summarize the motivation and sketch out some details of your idea.+    * You don't have to have everything figured out at this stage, and it's more important to emphasize the problems you are solving and why they're important than the nitty gritty details of how to solve them.+    * When you create a proposal, we will also automatically make a Zulip stream for discussion. The issue thread is reserved for summaries, announcements, or procedural updates.+* If the MCP is simple enough, the team may direct you to go straight to implementation.+    * In that case, you can create a PR against the rust-lang/rust repository.+* Otherwise, the proposal will require chartering a project group and drafting an RFC. This step requires a **lang-team liaison** who is willing and able to help the idea move forward.+    * The first step will be chartering a project group, which the liaison will help you with.+    * The charter is very similar to the MCP itself, and describes the motivation and other considerations that may have come up.+* Of course, many proposals will not be accepted. This can occur for a number of reasons:+    * There are no lang team members who have available bandwidth to serve as a liaison right now.+    * The problem being solved doesn't seem important enough or is not a match for Rust's current priorities.+    * The proposal has flaws in its design that don't seem like they can be solved.+    +## Flowchart++You can also view the [flowchart in graphical form][flowchart]. This+is derived from a [mermaid document][flowchart-source] and would be+posted on the lang-team website.++[flowchart]: https://is.gd/nMrsVE+[flowchart-source]: https://is.gd/LdRVWk++## Reasons to accept or decline a proposal++In the proposal stage, we are looking for proposals that have++* high motivation -- this is a good fit for the project's priorities+* available bandwidth -- there are lang team members who want to work on it as well as (if appropriate) members of other Rust teams++The focus is primarily on the motivation and secondarily on the solution(s) proposed. If we feel that the problem is worth solving, but the solutions have flaws that seem surmountable, it still makes sense to accept the proposal.++Reasons to decline a proposal, or to oppose the creation of a project group, include the following:++* The team has grave doubts about the feasibility of solving this problem.+    * When possible, though, it is better not to block a proposal on technical grounds. Instead, those grounds can be noted as something that must be resolved by the project group during the design process.+* There isn't available bandwidth to tackle the problem right now.+    * In particular, it may require input from particular members who have the requisite expertise, and they may be too busy with other things.+* The proposed solutions disproportionate to the scale of the problem.+    * For example, the solutions may be too invasive or they will likely be too much work to implement, and we can't really envision solutions that would +* The proposal is incomplete or is proposing a direction that seems wrong.+    * The team may ask for the proposal to include more potential solutions, or to be rewritten to emphasize a particular direction that we think would be better. If the author of the proposal disagrees with that direction, they should make the case for the existing solutions, but of course the proposal may not ultimately be accepted if the lang team doesn't find that case persuasive++## Simple MCPs can be implemented directly++In some cases, MCPs are sufficiently simple that we can just move straight to implementation. In this case, someone from the lang-team will leave a command indicating that we'd be happy to see a PR implementing this proposal and close the issue, and you can go ahead and create a PR against the rust-lang/rust repository directly. In that PR, you can cc the lang team and we will `fcp merge` the PR to make the final, official decision.++## Chartering a project group++For more complex MCPs, we will instead charter a [project group]. The goal of the group is to create an RFC. Chartering a project group is a lightweight process and a group doesn't necessarily imply a lot of people, it might just be one or two. But every project group always includs a liaison with the lang team. The job of a liaison is to help move the idea through the process. In some cases, they may actively help with the RFC and discussion in other cases they serve more as a bridge.++[project group]: https://github.com/rust-lang/rfcs/pull/2856++Mechanically, chartering a project group involves creating a PR against the rust-lang/lang-team repository with the charter text. The liaison will initiate an `rfcbot fcp merge` command, so that lang-team members can check their boxes to indicate they agree with chartering the new project group. This also initiates a Final Comment Period that is advertised to the broader community.++Writing a charter is not meant to be a big job. Often, it will suffice to copy over the MCP itself, perhaps with some light edits. However, in cases where there is a lot of discussion, charters should summarize the key points made during that discussion, and hence they can in some rare cases be longer.++## Declining a proposal++Proposals that are not accepted are called "declined". Proposals may be declined for many reasons and it does not mean that the proposal is not a good idea. Before closing issues, we try to leave comments laying out the reasoning behind the decision, but we also close issues in an automated fashion if they have not received comments from lang-team members after a certain period of time (this indicates a general lack of bandwidth to take on the proposal). Like any issue, closing an issue doesn't mean that that the proposal can never be re-opened, particularly if circumstances change in some way that invalidates the reasoning behind closing in the first place.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Template for lang-team MCPs++We will create a template for lang-team proposals that has the following sections:++* Summary+    * a few bullet points to capture the high-level concept+* Motivation and use-cases+    * examples of the problem being solved and why we care+* Links and related work+    * links to internals threads, other languages, etc+* Solution sketches+    * sketch of one or more ways to solve the problem++The intent is that proposals do not have to be exhaustively researched. They should contain enough details to understand the idea at a high level, but they don't have to have all the details worked out yet.++The intent is also that proposals will largely be accepted or declined "as is" -- if major changes are required, it is better to close and open a fresh proposal.++## Automation++We will have a bot that monitors proposals. The bot will take the following automated actions (though the details here are subject to change as we experiment).++* When an issue is opened with the Major Change Proposal template, it will be tagged as a "draft proposal".+    * An automated bot will create a dedicated Zulip topic in the `#t-lang/major changes` stream (same as the compile team process).+* (Optional) After N days without a comment from a lang-team member, an automated bot will indicate that the issue will be closed soon due to inactivity. After N more days, the issue is autoclosed.++## Transparency around bandwidth++As part of this process, the lang-team plans to organize and expose more clearly which project groups each member is currently involved with (likely using a Github project to expose details and other information). Similarly, we plan to communicate more clearly the sorts of proposals we are looking for at any period of time via blog posts or information on the [lang-team website].++[lang-team website]: https://lang-team.rust-lang.org/++## Transitioning to the new system++There are a number of existing RFCs, many of which have received quite a lot of work, that have to be transitioned to the new system. We do not want to just "auto close" all of those RFCs because in many cases they represent a significant amount of effort and "near consensus".++Our plan is to first create the new system and encourage folks to create proposals who wish to. Presuming our experience with the new system is positive, and once we have "ironed out the kinks", we will begin a process to port over the existing RFCs. ++The precise plans will be determined then, but they will likely include:++* A review of the RFCs to try and find those lang-team liaisons where possible.+* Announcing a date when we will complete the migate and posting a notice on existing RFCs. This notice would encourage others to try out the new process. After that date expires, existing RFCs would be closed.+* An alternative might be to "auto-migrate" all existing proposals via automation to create proposals, perhaps spaced out in groups.++# Drawbacks+[drawbacks]: #drawbacks++* There is an additional step to prepare an RFC, which indicates more overhead and procedures to be followed.++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++* We could have proposals be opened on the RFC repository+    * Why? Central place for all proposals across teams.+    * Why not? The RFC repository is no longer a "high signal" place to watch for "changes that have traction".+* We could try this for all teams at once.+    * Why? Uniform process is good.+    * Why not? Not sure how it will work, and each team has somewhat different needs.+* We could have MCPs be opened as a PR

So, one question is: where do we expect the discussion about a proposal to happen -- and, perhaps, who should be the participants?

In particular, on the compile team anyway, we've been pushing that discussion to Zulip, and I think that's been a net win over using github issues. The github issue is reserved for procedural or status updates.

We also don't generally have "long-lived" MCPs -- if there is a proposal and it changes drastically, we close it and open a new one.

nikomatsakis

comment created time in 3 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 5569b7a7321d89941899ccedb28e0a3881e0cf9d

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 3 days

issue commentrust-lang/rust

error: expected identifier when building time-macros-impl v0.1.1

Reading this thread, I have a few questions/comments:

  • Is there any documentation as to the expected behavior around procedural macros? My impression is that there is enough back-and-forth and questions on this thread about what the expected behavior is/ought-to-be that it would make sense to have a shared document that lays out our expectations.
  • How many more such discussions do we expect? One of @petrochenkov's comments sort of suggested there are more steps to take, it seems like it'd be good to communicate a bit more proactively next time, maybe setup a small Zulip stream or group to discuss?
  • I do agree with @Aaron1011 that this looks like a bugfix/change that should land eventually, but I do want to point out that even if a warning period is not feasible, it may make sense to revert and phase it in more gradually.
  • In particular, I imagine we could (a) have some documentation about the change and (b) make an announcement encouraging folks to upgrade to a new point release, that sort of thing.
tmiasko

comment created time in 3 days

issue commentrust-lang/compiler-team

Introduce `ty_error`/`ty_error_with_message`/`ty_error_const` to construct error type or const

For the record I think this idea is great!

mark-i-m

comment created time in 3 days

issue closedrust-lang/compiler-team

Reintegrate chalk into rustc

TL;DR

Reintegrate chalk into rustc using chalk-solve under the -Z chalk flag.

Links and Details

This is working towards the eventual™ goal of using Chalk as the rustc trait solver. There used to be an experimental implementation of Chalk in rustc using chalk-engine. It became outdated and was removed in https://github.com/rust-lang/rust/pull/69247. Since that first experimental implementation was added, Chalk has gone through lots of changes, including adding a new crate, chalk-solve, which is supposed to implement Rust logic. As such, with this newer implementation, the interface between rustc and Chalk is a bit higher-level.

The PR for this initial MVP implementation is here: https://github.com/rust-lang/rust/pull/69406

Mentors or Reviewers

c.c. @nikomatsakis c.c. @rust-lang/wg-traits

closed time in 3 days

jackh726
more