profile
viewpoint
Santiago Pastorino spastorino @wyeworks Montevideo, Uruguay https://santiagopastorino.com @wyeworks co-founder, @rust-lang compiler team contributor, @rustlatam organizer and @rails core team alumni.

http-rs/surf 835

Fast and friendly HTTP client framework for async Rust

rust-lang/rustc-dev-guide 628

A guide to how rustc works and how to contribute to it.

rust-lang/compiler-team 163

A home for compiler team planning documents, meeting minutes, and other such things.

rust-lang/cargo-bisect-rustc 53

Bisects rustc, either nightlies or CI artifacts

spastorino/coffee-rails 18

rails/coffee-rails is the official repo

spastorino/exceptron 9

Exceptron comes from the future to make your exceptions rock!

nikomatsakis/rust 7

A work-in-progress programming language; not yet suitable for users

spastorino/bundler 2

Gemfiles are fun

spastorino/arel 1

A Relational Algebra

spastorino/dalli 1

High performance memcached client for Ruby

push eventspastorino/arch-installation

Santiago Pastorino

commit sha 12924add54eb1440a018a475575f2c0f673a24c1

Remove Chromium Ozone aur

view details

push time in 12 hours

pull request commentrust-lang/rust-forge

Improve Prioritization procedure's summarize sections

Committed all @apiraino's suggestions. It should be ready to be merged now.

spastorino

comment created time in 3 days

push eventspastorino/rust-forge

Santiago Pastorino

commit sha 021b477b58384155d2651dcb6b896fa077c035ee

Update src/compiler/prioritization/procedure.md Co-authored-by: apiraino <apiraino@users.noreply.github.com>

view details

push time in 3 days

push eventspastorino/rust-forge

Santiago Pastorino

commit sha e4618611c27857a31bf0956630dc612e4d3d2221

Update src/compiler/prioritization/procedure.md Co-authored-by: apiraino <apiraino@users.noreply.github.com>

view details

push time in 3 days

push eventspastorino/rust-forge

Santiago Pastorino

commit sha 21e73467707eae13e65657ec70ce4c0eeb2a30de

Update src/compiler/prioritization/procedure.md Co-authored-by: apiraino <apiraino@users.noreply.github.com>

view details

push time in 3 days

pull request commentrust-lang/rust

Rename "cyclone" to "apple-a7" per changes in upstream LLVM

discussed in T-compiler meeting, backport rejected.

@rustbot modify labels: -stable-nominated

trevyn

comment created time in 5 days

pull request commentrust-lang/rust

Forbid non-derefable types explicitly in unsizing casts

discussed in T-compiler meeting.

@rustbot modify labels: beta-accepted

JohnTitor

comment created time in 5 days

pull request commentrust-lang/rust

forbid `#[track_caller]` on main

discussed in T-compiler meeting.

@rustbot modify labels: beta-accepted

lcnr

comment created time in 5 days

pull request commentrust-lang/rust

typeck: check for infer before type impls trait

Discussed in T-compiler meeting.

@rustbot modify labels: beta-accepted

davidtwco

comment created time in 5 days

PR opened rust-lang/rust-forge

Improve Prioritization procedure's summarize sections

Explain a bit better the Prioritization summarize process

cc @rust-lang/wg-prioritization

+19 -8

0 comment

1 changed file

pr created time in 5 days

create barnchspastorino/rust-forge

branch : prioritization-procedure-tweaks4

created branch time in 5 days

issue commentrust-lang/rust

Unexpected trait resolution overflow error

Should we assign this issue to @matthewjasper given that they will work on a backport?.

weiznich

comment created time in 5 days

issue commentrust-lang/rust

ICE on gigantic arrays

Assigning P-low as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

Soveu

comment created time in 5 days

pull request commentrust-lang/rust

forbid `#[track_caller]` on main

Adding missing T-compiler label so this is picked up by prioritization automation bot and placed into the compiler team meeting agenda.

lcnr

comment created time in 6 days

issue commentrust-lang/compiler-team-prioritization

Automate toolstate checks

In that case, what @rust-lang/wg-prioritization needs to do with toolstate then?. We've always had a hard time finding something useful to do regarding toolstate and in which the team would feel that is adding some kind of value.

spastorino

comment created time in 6 days

pull request commentrust-lang/rust

Add --run-stage and --link-stage aliases

:+1: to the idea of looking for more accurate names. In case this is a good idea for others, I'd suggest to deprecate/remove --stage X usage.

jyn514

comment created time in 6 days

issue openedrust-lang/compiler-team-prioritization

Automate toolstate checks

It would be nice if toolstate is broken for 5-7 days to re-ping people because definitely something has gone wrong and pinged people can fix that.

Toolstate website tells us when things are broken and that info is from some csv file iirc.

I'm not sure how simple is to figure out the tool existing issue and check for a broken since 5-7 days and then repost to Github.

cc @Mark-Simulacrum

created time in 6 days

pull request commentrust-lang/triagebot

Add lang agenda structure

This is good IMO, but @nikomatsakis doesn't it need to be a bit tweaked for the purposes of the lang agenda? or was your idea to adapt it afterwards?.

nikomatsakis

comment created time in 10 days

create barnchspastorino/arch-installation

branch : master

created branch time in 11 days

created repositoryspastorino/arch-installation

created time in 11 days

pull request commentrust-lang/rust

Separate unsized fn params from unsized locals

@JohnTitor thanks for taking this over because I couldn't check this issue again due to lack of time. This looks good to me but let's see what @RalfJung and @pnkfelix say about it.

JohnTitor

comment created time in 11 days

issue commentrust-lang/compiler-team-prioritization

Add command for relabeling issues from Zulip

Work by @LeSeulArtichaut that may help in this effort lives https://github.com/LeSeulArtichaut/triagebot/tree/zulip-commands

spastorino

comment created time in 11 days

push eventspastorino/triagebot

Santiago Pastorino

commit sha b3a96e2072b81649bb00554008a921782ae5ce7f

Add is: pr support for queries

view details

Santiago Pastorino

commit sha 40366c138f08398f741ef6ac12d9c28749616a60

Create lang agenda skeleton

view details

push time in 11 days

create barnchspastorino/triagebot

branch : add-lang-agenda-structure

created branch time in 12 days

issue commentrust-lang/compiler-team-prioritization

[Meta] Implement triagebot commands for each step of our procedure

When implementing part of this we can put back parts of the code removed in https://github.com/rust-lang/triagebot/pull/738 and https://github.com/rust-lang/triagebot/pull/739

spastorino

comment created time in 12 days

pull request commentrust-lang/triagebot

Remove prioritization steps

I've forgotten to remove templates in this PR. PR removing those is up here ... This https://github.com/rust-lang/triagebot/pull/739

spastorino

comment created time in 12 days

PR opened rust-lang/triagebot

Remove leftover templates from #738

This removes the templates that were forgotten on https://github.com/rust-lang/triagebot/pull/738

r? @Mark-Simulacrum

+0 -158

0 comment

5 changed files

pr created time in 12 days

create barnchspastorino/triagebot

branch : remove-prioritization-steps2

created branch time in 12 days

issue commentrust-lang/rust

Lifetime error when indexing with borrowed index in beta but not in stable

searched nightlies: from nightly-2020-06-19 to nightly-2020-07-11
regressed nightly: nightly-2020-06-20
searched commits: from https://github.com/rust-lang/rust/commit/e55d3f9c5213fe1a25366450127bdff67ad1eca2 to https://github.com/rust-lang/rust/commit/2d8bd9b74dc0cf06d881bac645698ccbcf9d9c5e
regressed commit: https://github.com/rust-lang/rust/commit/72417d84fb51495a4f1d007fb2397a0b2609ab63

Regressed in https://github.com/rust-lang/rust/pull/73504 which is a roll-up, likely https://github.com/rust-lang/rust/pull/72280

rodrimati1992

comment created time in 12 days

PR opened rust-lang/triagebot

Remove prioritization steps

This PR removes most of unused steps given that we now have a clear set of steps and more conviniently layed out in our procedure.

The steps may be useful in the future but as separate commands integrated in Zulip, basically for this issue https://github.com/rust-lang/compiler-team-prioritization/issues/8. Anyway, at that point we can just reuse the removed code in this PR.

r? @Mark-Simulacrum

cc @rust-lang/wg-prioritization

+5 -257

0 comment

3 changed files

pr created time in 12 days

create barnchspastorino/triagebot

branch : remove-prioritization-steps

created branch time in 12 days

issue commentrust-lang/rust

Unexpected trait resolution overflow error

@weiznich thanks for noting that, fixed the comment above and removed your link to avoid confusion.

weiznich

comment created time in 12 days

create barnchspastorino/rust-forge

branch : wg-prioritization-alerts

created branch time in 13 days

issue closedrust-lang/compiler-team

Move Rust provided objects, libraries and binaries meant for self-contained linkage to separate directory

Proposal

This affects only three targets: windows-gnu, linux-musl, -wasi. Currently startup objects (all three targets) and libraries (windows-gnu) and placed next to Rust's own libraries like libstd. This causes various problems, e.g. somebody wants to link external libraries with Rust but CRT shipped by Rust is incompatible with the one used to link external library. For windows-gnu there is also linker shipped.

https://github.com/rust-lang/rust/issues/68887#issuecomment-633048380 explains how to resolve that limitation by creating native and self-contained modes. Native mode would avoid using anything located inside self-contained directory.

https://github.com/rust-lang/rust/pull/72999 is preparation that moves things but retains old user visible behaviour (everything is linked just like before, only the paths are different).

Mentors or Reviewers

@petrochenkov

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 13 days

mati865

issue closedrust-lang/compiler-team

Add future-incompat entries to json diagnostic output

Proposal

Add future-incompat entries to json diagnostic output. (Also, ensure we always run code for future-incompatibility lints, even if they are allowed.)

This is part of https://github.com/rust-lang/rust/issues/71249 (rust-lang/rfcs#2834); it is the implementation of the rustc side of that feature.

This change is broken into these main parts:

  • In JSON diagnostic mode, if a future-incompatibility lint is triggered for a crate, regardless of the current lint level, it will issue at least one additional JSON output describing the lint.
    • My current plan is to have all such output be emitted at the end, after all other diagnostics.
    • The emitted diagnostics will include span info, when availble, so that client code can choose how best to present feedback about the problem to the end user.
  • For the initial deployment, use an allow-list so that only a subset of the current collection of future-incompatibility lints will actually trigger this new JSON emission. Over time we will increase the number of entries in the allow-list, with the hope of eventually removing the allow-list entirely once all the future-incompatibility lints are covered.
  • Extend compiletest to be able to handle the generated JSON output.
    • I want to test this feature within rustc's test suite on its own; therefore, compiletest will convert these generated JSON entries to stderr diagnostics (as opposed to just discarding them, as it currently does for artifact notifications), even though a normal user running in human-readable diagnostic mode will not observe them.
  • We need to also ensure that all future-incompatibility lint checks are executed (in order to observe this diagnostic) regardless of the current lint level. I have not yet surveyed the compiler to check the situation here.

Mentors or Reviewers

I have a prototype implementation: https://github.com/pnkfelix/rust/tree/prototype-rustc-side-of-report-future-incompat

I plan to mentor the work (or finish the above prototype).

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 13 days

pnkfelix

issue commentrust-lang/rust

linker-plugin-lto stopped working in Rust 1.45.0

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

heftig

comment created time in 13 days

issue commentrust-lang/rust

linker-plugin-lto stopped working in Rust 1.45.0

@rustbot ping cleanup

To see if we can minimize this issue.

heftig

comment created time in 13 days

issue commentrust-lang/rust

Unexpected trait resolution overflow error

Assigning P-critical as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

weiznich

comment created time in 13 days

issue commentrust-lang/rust

ICE: escaping bound vars in predicate

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

DutchGhost

comment created time in 13 days

issue commentrust-lang/rust

ICE with the `(foo @ ..,)` pattern

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

Also nominating for discussion given @petrochenkov's comments here and here.

namibj

comment created time in 13 days

pull request commentrust-lang/rust

Add the aarch64-apple-darwin target

Adding missing T-compiler label so it can be automatically picked up and placed in the weekly agenda.

shepmaster

comment created time in 13 days

pull request commentrust-lang/team

Add @lenary to RISC-V team

Hey @lenary good to see you here :wave:

lenary

comment created time in 13 days

issue openedrust-lang/rustc-dev-guide

rustc-middle shows up in text without explanation

rustc-middle, if I'm not wrong first shows up here https://rustc-dev-guide.rust-lang.org/overview.html#tyty without mentioning what is it about. It would be nice to link to some part that defines it or just a brief mention there of what's about.

created time in 14 days

create barnchspastorino/rustc-dev-guide

branch : fix-typo3

created branch time in 14 days

pull request commentrust-lang/rust-forge

Priority levels

@o0Ignition0o I'm not the one merging PRs here so I have no say about squashing or not :). Anyway IMHO this is ready cc @rust-lang/wg-prioritization

o0Ignition0o

comment created time in 15 days

pull request commentrust-lang/rust-forge

Priority levels

@o0Ignition0o great!, this is ready to land, just left really really minor nits. Once you can fix that I think it's ready to merge.

o0Ignition0o

comment created time in 15 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:++- P-critical+- P-high+- P-medium+- P-low++Each of these labels defines a strategy the team will adopt regarding:++- The amount of focus a given issue will receive+- How members of the community can get involved++## P-critical++A `P-critical` issue is a potentially blocker issue.++The Working Group will keep track of these issues and will remind the compiler team on a weekly basis during the triage meeting.++Examples of things we typically judge to be “critical” bugs:+- Regressions where code that used to compile no longer does+  - Mitigating conditions that may lower priority:+    - If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)+    - If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used+  - If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-critical but ended up being P-high](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)+- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)+  - Mitigating conditions that may lower priority:+    - If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)+- Feature-gated features accessible without a feature gate+  - Mitigating conditions that may lower priority:+    - If the pattern is VERY unlikely+- Soundness holes with real-world implications+  - Mitigating conditions that may lower priority:+    - Soundness holes that are difficult to trigger+    - Soundness holes that have been around for a very long time may be critical, but typically require+    - Soundness holes that will not affect stable, e.g. if the hole makes use of a gated unstable feature.+- Diagnostic regressions where the diagnostic is very common and the situation very confusing+- ICEs for common scenarios or code patterns+  - Mitigating conditions that may lower priority:+    - If the code that triggers the ICE also triggers compilation errors, and those errors are emitted before the ICE+    - If the code in question makes use of unstable features, particularly if the ICE requires a feature gate++A P-critical issue will receive the most attention. It must be assigned one or several people as soon as possible, and the rest of the team should do their best to help them out if/when applicable.++## P-high++`P-high` issues are issues that need attention from the compiler team, but not to the point that they need to be discussed at every meeting.+They can be `P-critical` issues that have a mitigating condition as defined above, or important issues that aren't deemed blockers.++Because there are too many `P-high` issues to fit in every compiler meeting, they should rather be handled asynchronously by the Prioritization WG, in order to help them move forward. They can still occasionally be brought up at meetings when it is deemed necessary.++The effectiveness of the Prioritization WG will be a direct consequence of our ability to draw the line between `P-critical` and `P-high` issues. There shouldn't be too many `P-critical` issues that compiler meetings become unmanageable, but critical issues shouldn't get lost in the list of P-high issues.++P-high issues are issues the teams will mostly work on. We want to make sure they're assigned, and keep an eye on them.++## P-medium and P-low++`P-medium` refer to issues that aren't a priority for the team, and that will be resolved in the long run. Eg issues that will be fixed after a specific feature has landed.++`P-low` refer to issues issue that the compiler team doesn't plan to resolve, but are still worth fixing.++P-medium issues won't be our focus. +They are issues we would mentor someone interested in fixing. +They will remain in this state until someone complains, a community member fixes it, or it gets fixed by accident.++---++###### For questions and comments about this document feel free to hit the relevant [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/What.20is.20the.20meaning.20of.20each.20priority.20level.3F) or [open an issue](https://github.com/rust-lang/rust-forge/issues).++######

Mainly this :point_up:

o0Ignition0o

comment created time in 15 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:++- P-critical+- P-high+- P-medium+- P-low++Each of these labels defines a strategy the team will adopt regarding:++- The amount of focus a given issue will receive+- How members of the community can get involved++## P-critical++A `P-critical` issue is a potentially blocker issue.++The Working Group will keep track of these issues and will remind the compiler team on a weekly basis during the triage meeting.++Examples of things we typically judge to be “critical” bugs:+- Regressions where code that used to compile no longer does+  - Mitigating conditions that may lower priority:+    - If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)+    - If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used+  - If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-critical but ended up being P-high](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)+- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)+  - Mitigating conditions that may lower priority:+    - If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)+- Feature-gated features accessible without a feature gate+  - Mitigating conditions that may lower priority:+    - If the pattern is VERY unlikely+- Soundness holes with real-world implications+  - Mitigating conditions that may lower priority:+    - Soundness holes that are difficult to trigger+    - Soundness holes that have been around for a very long time may be critical, but typically require+    - Soundness holes that will not affect stable, e.g. if the hole makes use of a gated unstable feature.+- Diagnostic regressions where the diagnostic is very common and the situation very confusing+- ICEs for common scenarios or code patterns+  - Mitigating conditions that may lower priority:+    - If the code that triggers the ICE also triggers compilation errors, and those errors are emitted before the ICE+    - If the code in question makes use of unstable features, particularly if the ICE requires a feature gate++A P-critical issue will receive the most attention. It must be assigned one or several people as soon as possible, and the rest of the team should do their best to help them out if/when applicable.++## P-high++`P-high` issues are issues that need attention from the compiler team, but not to the point that they need to be discussed at every meeting.+They can be `P-critical` issues that have a mitigating condition as defined above, or important issues that aren't deemed blockers.++Because there are too many `P-high` issues to fit in every compiler meeting, they should rather be handled asynchronously by the Prioritization WG, in order to help them move forward. They can still occasionally be brought up at meetings when it is deemed necessary.++The effectiveness of the Prioritization WG will be a direct consequence of our ability to draw the line between `P-critical` and `P-high` issues. There shouldn't be too many `P-critical` issues that compiler meetings become unmanageable, but critical issues shouldn't get lost in the list of P-high issues.++P-high issues are issues the teams will mostly work on. We want to make sure they're assigned, and keep an eye on them.++## P-medium and P-low++`P-medium` refer to issues that aren't a priority for the team, and that will be resolved in the long run. Eg issues that will be fixed after a specific feature has landed.++`P-low` refer to issues issue that the compiler team doesn't plan to resolve, but are still worth fixing.++P-medium issues won't be our focus. +They are issues we would mentor someone interested in fixing. +They will remain in this state until someone complains, a community member fixes it, or it gets fixed by accident.++---

Do the formatting starting here make sense?. I'm not sure what's the intention, not saying that is bad :smile: just wondering if these are leftovers

o0Ignition0o

comment created time in 15 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:++- P-critical+- P-high+- P-medium+- P-low++Each of these labels defines a strategy the team will adopt regarding:++- The amount of focus a given issue will receive+- How members of the community can get involved++## P-critical++A `P-critical` issue is a potentially blocker issue.++The Working Group will keep track of these issues and will remind the compiler team on a weekly basis during the triage meeting.++Examples of things we typically judge to be “critical” bugs:+- Regressions where code that used to compile no longer does+  - Mitigating conditions that may lower priority:+    - If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)+    - If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used+  - If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-critical but ended up being P-high](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)+- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)+  - Mitigating conditions that may lower priority:+    - If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)+- Feature-gated features accessible without a feature gate+  - Mitigating conditions that may lower priority:+    - If the pattern is VERY unlikely+- Soundness holes with real-world implications+  - Mitigating conditions that may lower priority:+    - Soundness holes that are difficult to trigger+    - Soundness holes that have been around for a very long time may be critical, but typically require+    - Soundness holes that will not affect stable, e.g. if the hole makes use of a gated unstable feature.+- Diagnostic regressions where the diagnostic is very common and the situation very confusing+- ICEs for common scenarios or code patterns+  - Mitigating conditions that may lower priority:+    - If the code that triggers the ICE also triggers compilation errors, and those errors are emitted before the ICE+    - If the code in question makes use of unstable features, particularly if the ICE requires a feature gate++A P-critical issue will receive the most attention. It must be assigned one or several people as soon as possible, and the rest of the team should do their best to help them out if/when applicable.++## P-high++`P-high` issues are issues that need attention from the compiler team, but not to the point that they need to be discussed at every meeting.+They can be `P-critical` issues that have a mitigating condition as defined above, or important issues that aren't deemed blockers.++Because there are too many `P-high` issues to fit in every compiler meeting, they should rather be handled asynchronously by the Prioritization WG, in order to help them move forward. They can still occasionally be brought up at meetings when it is deemed necessary.++The effectiveness of the Prioritization WG will be a direct consequence of our ability to draw the line between `P-critical` and `P-high` issues. There shouldn't be too many `P-critical` issues that compiler meetings become unmanageable, but critical issues shouldn't get lost in the list of P-high issues.++P-high issues are issues the teams will mostly work on. We want to make sure they're assigned, and keep an eye on them.++## P-medium and P-low++`P-medium` refer to issues that aren't a priority for the team, and that will be resolved in the long run. Eg issues that will be fixed after a specific feature has landed.++`P-low` refer to issues issue that the compiler team doesn't plan to resolve, but are still worth fixing.++P-medium issues won't be our focus. +They are issues we would mentor someone interested in fixing. +They will remain in this state until someone complains, a community member fixes it, or it gets fixed by accident.++---++###### For questions and comments about this document feel free to hit the relevant [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/What.20is.20the.20meaning.20of.20each.20priority.20level.3F) or [open an issue](https://github.com/rust-lang/rust-forge/issues).

If you consider leaving this, is the best to leave it as a title?

o0Ignition0o

comment created time in 15 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:++- P-critical+- P-high+- P-medium+- P-low++Each of these labels defines a strategy the team will adopt regarding:++- The amount of focus a given issue will receive+- How members of the community can get involved++## P-critical++A `P-critical` issue is a potentially blocker issue.++The Working Group will keep track of these issues and will remind the compiler team on a weekly basis during the triage meeting.++Examples of things we typically judge to be “critical” bugs:+- Regressions where code that used to compile no longer does+  - Mitigating conditions that may lower priority:+    - If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)+    - If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used+  - If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-critical but ended up being P-high](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)+- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)+  - Mitigating conditions that may lower priority:+    - If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)+- Feature-gated features accessible without a feature gate+  - Mitigating conditions that may lower priority:+    - If the pattern is VERY unlikely+- Soundness holes with real-world implications+  - Mitigating conditions that may lower priority:+    - Soundness holes that are difficult to trigger+    - Soundness holes that have been around for a very long time may be critical, but typically require+    - Soundness holes that will not affect stable, e.g. if the hole makes use of a gated unstable feature.+- Diagnostic regressions where the diagnostic is very common and the situation very confusing+- ICEs for common scenarios or code patterns+  - Mitigating conditions that may lower priority:+    - If the code that triggers the ICE also triggers compilation errors, and those errors are emitted before the ICE+    - If the code in question makes use of unstable features, particularly if the ICE requires a feature gate++A P-critical issue will receive the most attention. It must be assigned one or several people as soon as possible, and the rest of the team should do their best to help them out if/when applicable.++## P-high++`P-high` issues are issues that need attention from the compiler team, but not to the point that they need to be discussed at every meeting.+They can be `P-critical` issues that have a mitigating condition as defined above, or important issues that aren't deemed blockers.++Because there are too many `P-high` issues to fit in every compiler meeting, they should rather be handled asynchronously by the Prioritization WG, in order to help them move forward. They can still occasionally be brought up at meetings when it is deemed necessary.++The effectiveness of the Prioritization WG will be a direct consequence of our ability to draw the line between `P-critical` and `P-high` issues. There shouldn't be too many `P-critical` issues that compiler meetings become unmanageable, but critical issues shouldn't get lost in the list of P-high issues.++P-high issues are issues the teams will mostly work on. We want to make sure they're assigned, and keep an eye on them.++## P-medium and P-low++`P-medium` refer to issues that aren't a priority for the team, and that will be resolved in the long run. Eg issues that will be fixed after a specific feature has landed.++`P-low` refer to issues issue that the compiler team doesn't plan to resolve, but are still worth fixing.++P-medium issues won't be our focus. 
`P-medium` issues won't be our focus. 
o0Ignition0o

comment created time in 15 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:
Labeling an issue as `I-prioritize` starts the prioritization process, which will end by removing the `I-prioritize` label and appending one of the 4 labels we will discuss below:
o0Ignition0o

comment created time in 15 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.
`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-prioritize` label as described below.
o0Ignition0o

comment created time in 15 days

pull request commentrust-lang/rust

rustc_target: Add a target spec option for disabling `--eh-frame-hdr`

Thanks for adding T-compiler label @jonas-schievink. We missed this one on today's meeting because of the lack of T-compiler label. Anyway I check all the beta-nominations looking for nominations without team, the thing is I do that on wednesday and this one was tagged right after me going over all nominations.

Anyway, we will cover this one on our next meeting.

petrochenkov

comment created time in 18 days

issue commentrust-lang/compiler-team

Stabilizable subset of const generics

Prioritization automation failed because the bot didn't add the proposed-final-comment-period label. I've fixed T-compiler agenda manually. Maybe @rfcbot doesn't have permission to label issue in this repo?.

cc @Mark-Simulacrum

withoutboats

comment created time in 19 days

issue commentrust-lang/compiler-team

Infer hidden types without replacing with an inference variable

@matthewjasper right, I was too fast and did a quick pass just by checking labels. Anyway, I always review everything again on thursday so I guess I would have figured this mistake out :).

On the other hand, once a concern is raised and kind of "invalidates" the fact this was seconded, should the final-comment-period be removed and moved back to the proposed state or something like that?. Once your concerns are addressed, shouldn't this be reviewed again and eventually seconded again?. The current state of the proposals seems a bit confusing to me.

nikomatsakis

comment created time in 19 days

push eventspastorino/rust-forge

Santiago Pastorino

commit sha 8bd29418b9461bd660c416edead2e160e66d951f

Prioritization procedure: merge prioritization of regressions with I-prioritize issues Is not important to have a step for regressions because regressions are automatically labelled as `I-prioritize` and then covered by the previous section.

view details

push time in 19 days

create barnchspastorino/rust-forge

branch : prioritization-procedure-tweaks3

created branch time in 19 days

issue openedrust-lang/compiler-team-prioritization

Fix agenda's FCPs/MCPs announcement output

Right now there are 3 queries per step and we process one by one without aggregating. So, you get a list of the issues of the non empty queries but also get a there no issues this time bullet interleaved.

For instance what happens right now is ...

- Pending FCP requests (check your boxes!)
  - No pending FCP requests on compiler-team repo this time.
  - No pending FCP requests on rust repo this time.
  - No pending FCP requests on forge repo this time.
- Things in FCP (make sure you're good with it)
  - "Move Rust provided objects, libraries and binaries meant for self-contained linkage to separate directory" [compiler-team#310](https://github.com/rust-lang/compiler-team/issues/310)
  - "Add future-incompat entries to json diagnostic output" [compiler-team#315](https://github.com/rust-lang/compiler-team/issues/315)
  - "Infer hidden types without replacing with an inference variable" [compiler-team#325](https://github.com/rust-lang/compiler-team/issues/325)
  - No FCP requests on rust repo this time.
  - No FCP requests on forge repo this time.

But that should look more like ...

- Pending FCP requests (check your boxes!)
  - No pending FCP requests this time.
- Things in FCP (make sure you're good with it)
  - "Move Rust provided objects, libraries and binaries meant for self-contained linkage to separate directory" [compiler-team#310](https://github.com/rust-lang/compiler-team/issues/310)
  - "Add future-incompat entries to json diagnostic output" [compiler-team#315](https://github.com/rust-lang/compiler-team/issues/315)
  - "Infer hidden types without replacing with an inference variable" [compiler-team#325](https://github.com/rust-lang/compiler-team/issues/325)

created time in 19 days

pull request commentrust-lang/rust

Implement reentrance detection for std::sync::Once

This is right now tagged as waiting on team libs-impl but I think it's really waiting on T-libs team consensus. Going to label it accordingly but please feel free to correct me if I'm wrong.

nbdd0121

comment created time in 19 days

issue commentrust-lang/rust

Compiler doesn't terminate with --release

This was reconsidered, per @Mark-Simulacrum's comments and we consider now P-medium.

io12

comment created time in 20 days

issue commentrust-lang/rust

Compiler doesn't terminate with --release

Assigning P-critical as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

io12

comment created time in 20 days

issue closedrust-lang/compiler-team

Infer hidden types without replacing with an inference variable

Proposal

Summary

  • Change how we infer the types for opaque types
  • We would no longer replace opaque types with inference variables but would instead also use OpaqueType to represent them.
  • During unification, if an opaque type is "in scope" (i.e., we are within the defining scope), then we would convert any attempt to unify an opaque type with some other type T into an OpaqueTypeConstraint obligation and pass it back.
  • We would maintain separate "hidden types" for each opauqe type and update those with the results of the constraints separately, reporting an error if contradictory constraints arise.

Motivation

Our current opaque type implementation doesn't obey some parts of the impl Trait RFC and I don't quite see how it can.

For example, we'd like to support functions that just use opaque types, but place no constraints on the underlying hidden type, like this one:

type Foo = impl Iterator<Item = u32>;

fn unconstrained_parameter(mut f: Foo) {
    f.next();
}

Our current codebase assigns f an opaque type (sort of like proposed here), and so this may work, but then we'd also like to support cases that do constrain the opaque type, like this one:

type Foo = impl Sized;

fn constrain_parameter(f: Foo) {
    // Constraints `Foo` to be `u32`
    let x: u32 = f;
}

and this code currently gives a type check error.

Implications for users

I don't believe that this approach will really impact existing stable use cases for impl Trait. It does have some implications for users of unstable opaque types, though I think they are mostly beneficial:

  • Even before we've inferred what the opaque type O is, users can invoke methods on values of type O, as long as they come from the traits.
  • Values of type O are treated "opaquely" within their defining context, as well. They used to be treated as an inference variable and once that variable was bound they would be treated as the hidden type.

Potential breaking change

The final point can be a breaking change for stable code in one particular case. Consider this example (playground):

fn bar() -> impl Sized {
    let x: Box<dyn std::fmt::Debug> = Box::new(22);
    if false { return x; }
    if false { return Box::new(44); }
    Box::new(22)
}

fn main() {}

Here the first return x will infer the return type to Box<dyn Debug> which is then used to inform the other returns by forcing them to do a coercion. (Note that if you reorder those if statements, you'll find this code does not compile.)

We can do a crater run to see if this behavior matters. If necessary, we ought to be able to reproduce it by checking return statements that are returning to an opaque type and doing some kind of normalization, but I would rather not.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention then here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 20 days

nikomatsakis

issue closedrust-lang/compiler-team

Change `ty::Const` to a "value tree" representation

Proposal

Currently ty::Const has multiple ways of representing the same value, which by itself isn't bad, but we actually do represent the same value in different ways. This breaks the invariant in the compiler that if interned things are equal, their interned address is the same. This is very visible when you have two constants representing a pointer value. Const generic functions that are generic over pointer values can arbitrarily cause linker errors, because code defining the generic function may compute a different symbol than the code calling the generic function.

ty::Const's val field is of type ConstKind, whose Value variant contains a ConstValue. This ConstValue will be replaced by

enum ConstValue<'tcx> {
    Leaf(u128),
    Node {
        variant: Option<VariantIdx>,
        elements: &'tcx [ConstValue<'tcx>],
    }
}

This change will shrink the size of ConstValue from its current 32 bytes to 24 bytes. A value of struct, tuple or array type will be represented as a Node, where all the fields or elements are again encoded as ConstValue. Only integers, bools and char are allowed as Leaf values. A value of enum type will be represented as a Node where the variant field is set to the active enum variant's index and the enum variant's fields are encoded just like struct fields. A pointer is represented as a Node with a single child, so (42,) and &42 are represented exactly the same, only the type at the ty::Const level will differ. While we could have a separate Pointer(&'tcx ConstValue<'tcx>) variant, there's little use in making this explicit and not having it will reduce code duplication everwhere where the difference is not relevant without affecting the places where the difference is relevant.

A lossy conversion from mir::Const to ty::Const will be introduced. It will be used for pretty printing mir::Const during mir dumps. This way we only have to support pretty printing ty::Const, which is trivial to pretty print.

mir::Const will be changed to just become the old ConstValue::ByRef representation in case of ConstKind::Value. We can likely also remove other variants from the new mir::ConstKind - I belive Infer, Bound and PlaceHolder are only used in typeck and irrelevant for MIR.

Extensions and alternative designs are elaborated in https://hackmd.io/YmDjIsUsRrC6SiQzkl3Gew

Mentors or Reviewers

  • @eddyb already talked with me about this

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 20 days

oli-obk

issue closedrust-lang/compiler-team

Improve defaults in x.py

Proposal

  • Make the default stage dependent on the subcommand
  • Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want, use x.py build --stage 2 instead, which gives you a working libstd.
  • Change default debuginfo when debug = true from 2 to 1
  • Enable debug = true by default This change is no longer planned.

See also https://github.com/rust-lang/rust/pull/73964 which is a WIP which makes the changes in bootstrap, but not in CI or in the documentation.

Make the default stage dependent on the subcommand

x.py build/test: stage 1

I've seen very few people who actually use full stage 2 builds on purpose. These compile rustc and libstd twice three times and don't give you much more information than a stage 1 build (except in rare cases like https://github.com/rust-lang/rust/pull/68692#discussion_r376392145). For new contributors, this makes the build process even more daunting than it already is. As long as CI is changed to use --stage 2 I see no downside here.

x.py bench/dist/install: stage 2

These commands have to do with a finished, optimized version of rustc. It seems very rare to want to use these with a stage 1 build.

x.py doc: stage 0

Normally when you document things you're just fixing a typo. In this case there is no need to build the whole rust compiler, since the documentation will usually be the same when generated with the beta compiler or with stage 1.

Note that for this release cycle only there will be a significant different between stage0 and stage1 docs: https://github.com/rust-lang/rust/pull/73101. However most of the time this will not be the case.

Don't build stage1 rustc artifacts with x.py build --stage 1

Currently the behavior is as follows (where stageN <-> stage(N-1) artifacts, except for stage0 libstd):

  • x.py build --stage 0:
    • stage0 libstd
    • stage0 rustc (but without putting rustc in stage1/)

This leaves you without any rustc at all except for the beta compiler (https://github.com/rust-lang/rust/issues/73519). This is never what you want (currently you should use either x.py check or x.py build --stage 0 src/libstd instead).

  • x.py build --stage 1:
    • stage0 libstd
    • stage0 rustc
    • stage1 libstd
    • stage1 rustc
    • stage1 rustdoc

This leaves you with a stage1 rustc which doesn't even have libcore and is effectively useless. Additionally, it compiles rustc twice, which is not normally what you want.

  • x.py build --stage 2:
    • stage0 libstd
    • stage0 rustc
    • stage1 libstd
    • stage1 rustc
    • stage2 libstd
    • stage2 rustc
    • stage2 rustdoc

This builds the whole source tree in release mode. This is the correct usage for CI, but takes far too long for development.

The proposed new behavior is as follows:

  • x.py build --stage 0:
    • stage0 libstd

This is suitable for contributors only working on the standard library, as it means rustc never has to be compiled.

  • x.py build --stage 1:
    • stage0 libstd
    • stage0 rustc
    • stage1 libstd
    • stage1 rustdoc

This is suitable for contributors working on the compiler. It ensures that you have a working rustc and libstd without having to pass src/libstd in addition.

  • x.py build --stage 2:
    • stage0 libstd
    • stage0 rustc
    • stage1 libstd
    • stage1 rustc
    • stage2 libstd
    • stage2 rustdoc

This is suitable for debugging failures which only occur the second time rustc is built.

CI wants even more than this: x.py build --stage 2 + stage2 rustc. There will be a new option added to meet this use case: x.py build src/rustc.

To get the previous behavior of x.py build --stage 1, use x.py build --stage 2 src/libstd, which also builds a working libstd, but does not build the release tools. --stage 2 works the same, and --stage 0 was broken anyway.

Change default debuginfo when debug = true from 2 to 1

From a conversation in discord:

Linking seems to consume all available RAM, leading to the OS to swap memory to disk and slowing down everything in the process Compiling itself doesn't seem to take up as much RAM, and I'm only looking to check whether a minimal testcase can be compiled by rustc, where the runtime performance isn't much of an issue

do you have debug = true or debuginfo-level = 2 in config.toml? if so I think that results in over 2GB of debuginfo nowadays and is likely the culprit which might mean we're giving out bad advice :(

There is another conversation about how debuginfo-level is painful on Zulip.

Anecdotally, this sped up my stage 1 build from 15 to 10 minutes. It still adds line numbers, it only removes variable and type information.

Enable debug = true by default

This allows contributors to get RUST_LOG=debug messages without having to modify config.toml. It also enables debug assertions by default.

This change is no longer planned.

Mentors or Reviewers

I do not have a mentor in mind. I do know several people who have expressed interested in having different defaults: @eddyb, @joshtriplett, @pnkfelix, various others.

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [x] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 20 days

jyn514

issue closedrust-lang/compiler-team

Use `tracing` instead of `log`

Proposal

  1. Replace all uses of the log crate with tracing (there are verbatim replacements for the logging macros, so no code changes)
  2. Replace all uses of {:?} in tracing macro invocations with ?value infront of the format string
  3. Introduce span! invocations to give us hirerarchical logs

Mentors or Reviewers

  • @oli-obk

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 20 days

oli-obk

issue commentrust-lang/rust

ICE: bad_placeholder_type

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

Bryysen

comment created time in 20 days

issue commentrust-lang/rust

Stack overflow in rustc, regression from 1.44

It would be nice to bisect this one if possible ...

@rustbot ping cleanup

alexcrichton

comment created time in 20 days

issue commentrust-lang/rust

Stack overflow in rustc, regression from 1.44

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

alexcrichton

comment created time in 20 days

pull request commentrust-lang/rust

Don't panic if the lhs of a div by zero is not statically known

Adding T-compiler label so we can go through this nomination during T-compiler meeting.

oli-obk

comment created time in 20 days

pull request commentrust-lang/rust

improper_ctypes_definitions: allow `Box`

Adding T-compiler label so we can go through this nomination during T-compiler meeting.

davidtwco

comment created time in 20 days

PR opened rust-lang/rust

Use forge links for prioritization procedure

r? @Mark-Simulacrum

cc @rust-lang/wg-prioritization

+7 -7

0 comment

1 changed file

pr created time in 21 days

create barnchspastorino/rust

branch : fix-prioritization-procedures-links

created branch time in 21 days

push eventspastorino/rust

Santiago Pastorino

commit sha cf52d5fb87dc53b69f04416cc4080de807b7fd76

Use forge links for prioritization procedure

view details

push time in 21 days

push eventspastorino/rust

Dennis Duda

commit sha 41d540fcb72ccef0e1c20f145288993a41260e25

Unify temp path generation for non-android

view details

Dennis Duda

commit sha 577ac2f836f860646ca4f47a5effcfe6f024ec39

Fix `set_permissions` call for non-windows

view details

Dennis Duda

commit sha 0199fdc0f72ec6942d93d0bf23c7fa1fb9fbf54f

Update help text of remote-test-client to reflect changed command

view details

Dennis Duda

commit sha 036da3a6dcc084db90dbe6ea2831eb7332a1c535

Make `remote-test-client` work as cargo runner again Since cargo appends executable/args, the support_lib count parameter has to come first.

view details

Michael Wright

commit sha 6122612232976c1ac766a5d415265eb3eb30e72c

Increase cargo_metadata version to 0.9.1 `clippy_lints` makes use of `dep_kinds` on `NodeDep` but this was only added in versoin 0.9.1. Compiling with 0.9.0 will fail because of this.

view details

flip1995

commit sha 0ab823c509897ce2f516feb760fe1bf02cf77443

Rework suggestion generation of `unit_arg` lint

view details

flip1995

commit sha 380d941a045dc213ae28807d74fc32d1b1841e22

Adapt stderr and fixed files

view details

flip1995

commit sha a1a1a4b82a35b810570dbf7d2ee7f00896bee232

Use multiple span_suggestions instead of multipart_suggestion multipart suggestions aren't autofixable by rustfix yet

view details

flip1995

commit sha 0f69cafc2dd77d573e24870887a4a13cfe50515a

Rework suggestion generation and use multipart_suggestion again

view details

flip1995

commit sha f9c325f5b657e0c37ba2016a51cddbeab7f7693f

Suggest to remove the semicolon of the last stmt in a block

view details

flip1995

commit sha 4c9cefa12232aa0224b1680f51654fe10f5cf3b7

Move linting out in its own function

view details

flip1995

commit sha 6d15a149640e5647ce232690d54b540346fa1641

Update test files

view details

bors

commit sha 5fd2f06e99a985dd896684cb2c9f8c7090eca1ab

Auto merge of #72767 - pnkfelix:track-devirtualized-filenames-issue-70924, r=eddyb Track devirtualized filenames Split payload of FileName::Real to track both real and virtualized paths. (Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`) This way, we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR #70642) that ends up in incremental build artifacts, while still using the devirtualized file path when we want to access the file. Fix #70924

view details

Amanieu d'Antras

commit sha d49020573c34611b748b2d7737563f594f5c0215

Clarify errors and warnings about the transition to the new asm!

view details

flip1995

commit sha a9cde3a804808e82402888a20878053404a8eded

Don't suggest to move empty blocks

view details

flip1995

commit sha 77dd0ea62aa6a2af70da4c5e05de064eee182a6c

Add tests for empty blocks

view details

bors

commit sha fcc3ed2cdc442b4d3b8f1cb2be5ef7686ff89b3c

Auto merge of #5669 - mikerite:fix-cargo_metadata-0.9, r=phansch Increase cargo_metadata version to 0.9.1 `clippy_lints` makes use of `dep_kinds` on `NodeDep` but this was only added in versoin 0.9.1. Compiling with 0.9.0 will fail because of this. changelog: none

view details

bors

commit sha 9fdcb13edb4026d1058c793a553f1798c044870c

Auto merge of #4455 - flip1995:unit_arg_appl, r=phansch Rework suggestion generation of `unit_arg` lint Found this bug while running `cargo fix --clippy` on quite a big codebase: This would replace something like: ```rust Some(fn_that_actually_does_something(&a, b)) ``` with ```rust Some(()) ``` which obviously suppresses side effects. Since pretty much every expression could have side effects, I think making this suggestion `MaybeIncorrect` is the best thing to do here. A correct suggestion would be: ```rust fn_that_actually_does_something(&a, b); Some(()) ``` Somehow the suggestion is not correctly applied to the arguments, when more than one argument is a unit value. I have to look into this a little more, though. changelog: Fixes suggestion of `unit_arg` lint, so that it suggests semantic equivalent code Fixes #4741

view details

Miller

commit sha 186b274fd934ab4a7b2211954046d58164781f9e

changed *nix to Unix-like

view details

JOE1994

commit sha dd0338fbac143cb0c3844575f5ae4406854b56c5

Clarify terms in doc comments Doc comments of 'copy_from_slice' say that people should use 'clone_from_slice' when 'src' doesn't implement 'Copy'. However, 'src' is a reference and it always implements 'Copy'. The term 'src' should be fixed to 'T' in the doc comments. Thank you for reviewing this PR :)

view details

push time in 22 days

create barnchspastorino/rust

branch : ice-should-print-query-stack

created branch time in 22 days

pull request commentrust-lang/rust-forge

Priority levels

This looks like almost done to me. One thing I'd do is do not list the priorities twice, just make one list with the definitions of the priorities and with the frequency of checking them and all that. I guess summarizing the document and keeping it shorter it's better if we can make that in a clean way.

o0Ignition0o

comment created time in 22 days

Pull request review commentrust-lang/rust-forge

Priority levels

+# Priority levels++As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.++## Words used in this document:++`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-Prioritize` label as described below.++This document will define what each label means, and what strategy for each label will be used.++## Labels++Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending one of the 4 labels we will discuss below:++- P-Critical+- P-High+- P-Medium+- P-Low++Each of these labels defines a strategy the team will adopt regarding:++- The amount of focus a given issue will receive+- How members of the community can get involved++## Definitions++### P-Critical++A `P-Critical` issue is a potentially blocker issue.++The Working Group will keep track of the number of such issues open at the same time (which shouldn't be more than 5), and how long such issues remain open.++Examples of things we typically judge to be “critical” bugs:++- Regressions where code that used to compile no longer does++  - Mitigating conditions that may lower priority:+    - If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)+    - If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used+  - If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-Critical but ended up being P-High](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)++- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)+  - Mitigating conditions that may lower priority:+    - If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)+- Feature-gated features accessible without a feature gate+  - Mitigating conditions that may lower priority:+    - If the pattern is VERY unlikely+- Soundness holes where common code that should not compile actually does+  - Mitigating conditions that may lower priority:+    - Soundness holes that are difficult to trigger+    - Soundness holes that have been around for a very long time may be critical, but typically require+- Diagnostic regressions where the diagnostic is very common and the situation very confusing

I guess we can just leave it there, would be useful as a reminder. Of course the phrase is correct in some sense, if the compilation error is completely misleading for a very common thing, I guess the issue is P-critical, imagine a move error being reported as a something completely misleading.

o0Ignition0o

comment created time in 22 days

pull request commentrust-lang/rust-forge

Priority levels

src/compiler/prioritization.md can be removed from this PR.

o0Ignition0o

comment created time in 22 days

Pull request review commentrust-lang/rust-forge

Priority levels

     - [So you want to add a new option to rustc?](./compiler/new_option.md)     - [Major Change Proposals](./compiler/mcp.md)     - [Membership](./compiler/membership.md)+    - [Prioritization](./compiler/prioritization.md)+        - [Priority Levels](./compiler/prioritization/priority-levels.md)

This needs to be rebased.

o0Ignition0o

comment created time in 22 days

pull request commentrust-lang/rustc-dev-guide

Expand on the documentation for polymorphization.

Let's wait for it to land and re-run the CI then. Thanks @davidtwco for documenting this :heart:

davidtwco

comment created time in 25 days

issue commentrust-lang/rust

Borrowck deduces empty lifetime

Assigning P-critical as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

dingxiangfei2009

comment created time in 25 days

pull request commentrust-lang/rust

Remove leftover from emscripten fastcomp support

@bors r+ rollup=always

bjorn3

comment created time in 25 days

issue commentrust-lang/compiler-team-prioritization

Add to-announce to FCPs once they are finished

If they are properly tagged I'd say only T-compiler ones.

spastorino

comment created time in a month

issue commentrust-lang/compiler-team-prioritization

Add to-announce to FCPs once they are finished

@LeSeulArtichaut I've talked to Niko, we agreed on this and just created the label.

spastorino

comment created time in a month

issue commentrust-lang/rust

Compiler doesn't terminate with --release

@estebank I think this is worth a nomination as you have done, but I'm interested in hearing from you what's the reason for the nomination. What's exactly what you wanted to discuss during the meeting about this issue?.

io12

comment created time in a month

more