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 695

Surf the web – HTTP client framework

rust-lang/rustc-guide 535

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

rust-lang/compiler-team 131

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

rust-lang/cargo-bisect-rustc 41

Bisects rustc, either nightlies or CI artifacts

spastorino/coffee-rails 19

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

Pull request review commentrust-lang/cargo-bisect-rustc

[WIP] Link to current nightly

 impl Toolchain {     }      fn remove(&self, dl_params: &DownloadParams) -> Result<(), Error> {-        if !self.is_current_nightly() {-            eprintln!("uninstalling {}", self);-            let dir = dl_params.install_dir.join(self.rustup_name());-            fs::remove_dir_all(&dir)?;-        }+        eprintln!("uninstalling {}", self);+        self.do_remove(dl_params)+    }++    /// Removes the (previously installed) bisector rustc described by `dl_params`.+    ///+    /// The main reason to call this (instead of `fs::remove_dir_all` directly)+    /// is to guard against deleting state not managed by `cargo-bisect-rustc`.+    fn do_remove(&self, dl_params: &DownloadParams) -> Result<(), Error> {+        let rustup_name = self.rustup_name();++        // Guard aginst destroying directories that this tool didn't create.+        assert!(rustup_name.starts_with("bisector-nightly") ||+                rustup_name.starts_with("bisector-ci"));

I understand this idea and seems good but given that we are naming the default installation as nightly https://github.com/rust-lang/cargo-bisect-rustc/pull/55/files#diff-639fbc4ef05b315af92b4d836c31b023R737 I don't see how are we avoiding to call do_remove for the default nightly installations.

pnkfelix

comment created time in 12 hours

Pull request review commentrust-lang/cargo-bisect-rustc

[WIP] Link to current nightly

 impl Toolchain {     }      fn remove(&self, dl_params: &DownloadParams) -> Result<(), Error> {-        if !self.is_current_nightly() {-            eprintln!("uninstalling {}", self);-            let dir = dl_params.install_dir.join(self.rustup_name());-            fs::remove_dir_all(&dir)?;-        }+        eprintln!("uninstalling {}", self);+        self.do_remove(dl_params)+    }++    /// Removes the (previously installed) bisector rustc described by `dl_params`.+    ///+    /// The main reason to call this (instead of `fs::remove_dir_all` directly)+    /// is to guard against deleting state not managed by `cargo-bisect-rustc`.+    fn do_remove(&self, dl_params: &DownloadParams) -> Result<(), Error> {+        let rustup_name = self.rustup_name();++        // Guard aginst destroying directories that this tool didn't create.
        // Guard against destroying directories that this tool didn't create.
pnkfelix

comment created time in 12 hours

push eventrust-lang/cargo-bisect-rustc

Felix S. Klock II

commit sha 90f0ac8d867ca270fc57aed4c55f1aa68fb6b179

refactored code to add stage that can process output to decide outcome based on more subtle predicate than just `exit_status.success()`.

view details

Felix S. Klock II

commit sha ff8a0753dcb12f58be2f21b40ff9c61ad2debbfc

Added `--regress=ice` flag to resolve #34. Also added some other variants, to resolve #28. Just to spell it out: * --regress=error is the default: an error status (program rejection or ICE) is a regression. * --regress=success is probably what you want for #28, to see where a fix was injected. * --regress=ice is what you want if you're looking for where an ICE was injected. * --regress=non-error is what you want if you know the code should be a static error, but the bug is causing either ICEs or invalid successes to show up.

view details

Santiago Pastorino

commit sha 7ac03973cd216782fe93858d14e5897f409732d8

Merge pull request #53 from pnkfelix/issue-34-add-ice-mode Add --regress=regression-type command line option.

view details

push time in 18 hours

PR merged rust-lang/cargo-bisect-rustc

Add --regress=regression-type command line option.

Added --regress=ice flag to resolve #34.

Also added some other variants, to resolve #28.

Here are all the variants provided:

  • --regress=error is the default: an error status (program rejection or ICE) is a regression.

  • --regress=success is probably what you want for #28, to see where a fix was injected.

  • --regress=ice is what you want if you're looking for where an ICE was injected.

  • --regress=non-error is what you want if you know the code should be a static error, but the bug are causing either ICEs or invalid acceptances to show up, and you want to identify the first occurrence of either. (Sounds like a pretty niche case, I admit.)


One potentially subtle point: In order to post-process the error output, I had to capture it. The code prior to this PR never captured stdout/stderr; it either directed it to /dev/null, or inherited its parent's IO descriptors.

I didn't see a convenient way to get a tee effect (i.e. the ideal thing would be to both capture the output but also emit it, without internally buffering and re-emitting it (*)). Since I didn't see a way to do tee, I did the simple dumb thing: If we need to capture the output, then we do so. But if we do that in a context where the code was previously inheriting the descriptors, then we also re-emit the output after it runs.

(The main consequence of this, I think, is that you will lose the timing information of how the output to stdout and stderr was originally interleaved.)

(*): then again, maybe tee buffers as well, at least by default? What do i know...

+152 -18

2 comments

1 changed file

pnkfelix

pr closed time in 18 hours

issue closedrust-lang/cargo-bisect-rustc

feature request: Invert status

Add ability to look for any change in success status. i.e. not only went from good to bad, but also from bad to good.

closed time in 18 hours

nagisa

issue closedrust-lang/cargo-bisect-rustc

Flag to check for internal compiler errors

It would be nice as a convenience if this could provide an --ice flag to check specifically for internal compiler errors rather than any error.

closed time in 18 hours

fenhl

pull request commentrust-lang/cargo-bisect-rustc

Add --regress=regression-type command line option.

@pnkfelix this is great :). Please let me know when you finish investigating this and I can merge.

pnkfelix

comment created time in 18 hours

create barnchspastorino/rust

branch : mir-not-an-experiment

created branch time in 20 hours

PR opened rust-lang/rust

MIR is not an experiment anymore

r? @oli-obk

+1 -1

0 comment

1 changed file

pr created time in 20 hours

push eventrust-lang/compiler-team

Wesley Wiser

commit sha 106c6d939b5f240147217a417f5e56bd46118d72

Add notes for compiler team triage meeting on 2020-02-013

view details

Santiago Pastorino

commit sha 426f8d7aae21bcfa00b12114eb6aa7aa8e9dce06

Merge pull request #249 from rust-lang/wesleywiser-patch-2 Add notes for compiler team triage meeting on 2020-02-013

view details

push time in 2 days

pull request commentrust-lang/rustc-guide

Document ./x.py fmt

I think after addressing what @LeSeulArtichaut have said this is good to be merged.

mark-i-m

comment created time in 3 days

push eventrust-lang/rustc-guide

Who? Me?!

commit sha 3dd93bf6b925cac28bd14650900b456e156e7951

spit of type folder and generics subchapters (#586)

view details

push time in 3 days

PR merged rust-lang/rustc-guide

Split of type folder and generics subchapters

as discussed in #530

+251 -248

0 comment

4 changed files

mark-i-m

pr closed time in 3 days

pull request commentrust-lang/cargo-bisect-rustc

Fix toolchain name when a bisect range bound lands on the default nightly's date

@lqd I was about to merge but ended with doubts. Did we say that the approach @Mark-Simulacrum has mentioned here https://github.com/rust-lang/cargo-bisect-rustc/pull/45#issuecomment-584162469 doesn't work? or what was the deal with it?.

lqd

comment created time in 3 days

push eventspastorino/rustc-guide

Santiago Pastorino

commit sha a64440b9d7e35503433d1f115dceee44fe271890

Remove typo

view details

push time in 4 days

push eventspastorino/rustc-guide

Santiago Pastorino

commit sha f6b1dfa005b30eba821c223905c535b50ec9bac2

This page is diagnostics.html now

view details

push time in 4 days

issue commentrust-lang/rustc-guide

Explain the technical parts of the Walkthrough somewhere

Well I'm having second thoughts if this is a good example for what I'm thinking right now. But would be nice to explain a PR that touches a lot of the different parts of the compiler.

spastorino

comment created time in 4 days

issue openedrust-lang/rustc-guide

Explain the technical parts of the Walkthrough somewhere

Was reading this https://rust-lang.github.io/rustc-guide/walkthrough.html and I thought that it could be very nice if we can explain the actual code of the PR. It seems like a feature that touches a lot of parts of the compiler so it may be a good idea to explain things there or later in the guide but using this same example.

cc @mark-i-m

created time in 4 days

push eventspastorino/rustc-guide

Santiago Pastorino

commit sha 594e73c85aa98d973a7eba6a7e8928bf6fa21290

It may Take a lot of time instead of 2 hours

view details

push time in 5 days

push eventspastorino/rustc-guide

Santiago Pastorino

commit sha 5e43b9251cc9ae85b7592b55a92025c94570680e

All the text is at the time of this writing

view details

Santiago Pastorino

commit sha b0f05a3136ca66117d24737e46d701a0dda5752f

Reformat lines length of modified paragraph

view details

push time in 5 days

create barnchspastorino/rustc-guide

branch : some-fixes

created branch time in 5 days

created tagspastorino/system76-firmware

tag1.0.7-patched

System76 Firmware Tool and Daemon

created time in 6 days

push eventspastorino/system76-firmware

push time in 6 days

push eventspastorino/system76-firmware

Santiago Pastorino

commit sha 1347d2f1ee889d4bf0e287363a56d11ef8b84407

1.0.7.tar.gz

view details

push time in 6 days

push eventspastorino/system76-firmware

Santiago Pastorino

commit sha 77832438225002921516f6e8f491f93a8df73ee8

Use /boot as the efi directory

view details

push time in 6 days

fork spastorino/system76-firmware

System76 Firmware Tool and Daemon

fork in 6 days

issue openedrust-lang/rustc-guide

Document fmt in Other Tests

It would be nice to document that we are testing the code is fmted here https://rust-lang.github.io/rustc-guide/tests/intro.html#other-tests

created time in 9 days

pull request commentrust-lang/cargo-bisect-rustc

Fix toolchain name when a bisect range bound lands on the default nightly's date

@lqd I was wondering, should we apply this as is for now and release meanwhile we find a proper solution?. My feeling is that anything would be better to what we already have :).

lqd

comment created time in 9 days

push eventrust-lang/rustc-guide

Youngsuk Kim

commit sha df680be24bb9b29b858cc3e3f264975f8e083554

Correction of type name (#576) `ConstraintSet` => `OutlivesConstraintSet`

view details

push time in 10 days

PR merged rust-lang/rustc-guide

Correction of type name

ConstraintSet => OutlivesConstraintSet

+2 -2

0 comment

1 changed file

JOE1994

pr closed time in 10 days

pull request commentrust-lang/team

Add Yerke to Cleanup Crew ICE-breakers

@nikomatsakis close this one in favor of #252

yerke

comment created time in 11 days

pull request commentrust-lang/team

Add ethanboxx to Cleanup Crew ICE-breakers

@nikomatsakis close this one in favor of #252

ethanboxx

comment created time in 11 days

pull request commentrust-lang/team

Add matheus-consoli to Cleanup Crew ICE-breakers

@nikomatsakis close this one in favor of #252

matheus-consoli

comment created time in 11 days

pull request commentrust-lang/team

Add h-michael to Cleanup Crew ICE-breakers

@nikomatsakis close this one in favor of #252

h-michael

comment created time in 11 days

PR opened rust-lang/team

Cleanup crew rollup

This superseeds #245, #247, #248 and #250

+18 -0

0 comment

5 changed files

pr created time in 11 days

create barnchspastorino/team

branch : cleanup-crew-rollup

created branch time in 11 days

pull request commentrust-lang/team

added robertosnap to team - Cleanup Crew ICE-breakers

@RobertoSnap you need to actually add yourself to the team. Check the PR example to figure out how to do that :).

RobertoSnap

comment created time in 11 days

push eventrust-lang/compiler-team

Wesley Wiser

commit sha 4e4d9dc7a75a6ea1c12f3aac82c0a9b6743d4d36

Add compiler team triage meeting notes for 2020-02-06

view details

Santiago Pastorino

commit sha c4a7418e609129589c05dedcc2085d69cbd99227

Merge pull request #246 from rust-lang/wesleywiser-patch-1 Add compiler team triage meeting notes for 2020-02-06

view details

push time in 15 days

create barnchspastorino/blog.rust-lang.org

branch : fix-list-style

created branch time in 16 days

push eventspastorino/blog.rust-lang.org

Santiago Pastorino

commit sha 9807a5df7b6fe12d932504098b5038677e270131

Update Cleanup-Crew post date

view details

push time in 16 days

push eventspastorino/blog.rust-lang.org

Santiago Pastorino

commit sha d7a66927e236c350725c463d89c6e0ede344f85c

Update posts/inside-rust/2020-01-27-Cleanup-Crew-ICE-breakers.md Co-Authored-By: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com>

view details

push time in 16 days

push eventspastorino/blog.rust-lang.org

Santiago Pastorino

commit sha 329ece6f8c89989b11543c41c9dc170e971ba607

Fix link

view details

push time in 16 days

push eventspastorino/blog.rust-lang.org

Santiago Pastorino

commit sha 53f83e0a650d7b3b74a7b624901bb39f5694aa1c

Update posts/inside-rust/2020-01-27-Cleanup-Crew-ICE-breakers.md Co-Authored-By: Niko Matsakis <niko@alum.mit.edu>

view details

push time in 16 days

pull request commentrust-lang/rustc-guide

mir: begin documenting user variable debuginfo.

@eddyb cool, I was wondering if something could also be documented on rustc-guide :).

eddyb

comment created time in 19 days

pull request commentrust-lang/rustc-guide

Update sanitizers documentation

Thanks @tmiasko for the update, I'd wait for rust-lang/rust#68164 to land then.

tmiasko

comment created time in 19 days

issue commentrust-lang/cargo

Cargo is entering an infinite loop

Unsure if the pushed patch fixes the problem you're seeing. I can't even try this, getting OOM when trying to compile cargo with and without this patch.

ehuss

comment created time in 25 days

PR opened rust-lang/cargo

Swap std::sync::mpsc channel with crossbeam_channel

Switching this hoping it closes #7840

r? @Mark-Simulacrum

+3 -2

0 comment

2 changed files

pr created time in 25 days

create barnchspastorino/cargo

branch : fix-infinite-loop

created branch time in 25 days

push eventspastorino/rust

Santiago Pastorino

commit sha 3021856626974eb571b59ebd549661f11290f32a

Fix some wrong dereferences after rebase

view details

push time in 25 days

push eventspastorino/rust

Markus Westerlind

commit sha a5657dbc43d84133bd95e5de178d68634973b1b3

perf: Avoid creating a SmallVec if nothing changes during a fold Not sure if this helps but in theory it should be less work than what the current micro optimization does for `ty::Predicate` lists. (It would explain the overhead I am seeing from `perf`.)

view details

Markus Westerlind

commit sha 898ed636a3f44e3aa0156c1bb5ebc86b08aef5fa

Fix copy_from_slice which should be extend_from_slice

view details

Thom Chiovoloni

commit sha 6a7a69bde9813ac2868f36a01567c633ed6cd023

Add {leading,trailing}_ones to primitive int types

view details

Thom Chiovoloni

commit sha 2330e325ccee2e91d7aec6c0d4068748619bf588

Tests for leading_trailing_ones

view details

Markus Westerlind

commit sha a1586f1d2b17d687444d3b94aedd7ce24ae074ed

Explain fold_list

view details

CAD97

commit sha f76177ce4376ea15b1b303da347e8f653679cf88

Stabilize ptr::slice_from_raw_parts[_mut]

view details

Thom Chiovoloni

commit sha 783a7dc8ed03a38910b9ea5ded11139616dfa67b

Mark leading_trailing_ones with tracking issue 57969

view details

CAD97

commit sha 1c0d4851a6a686d09b03fab575fb0847d1e9f665

Fix incorrect slice->ptr conversion in slice_from_raw_parts docs

view details

csmoe

commit sha 42b6ed13be779499d118af721913a66bd3d946ea

account temporary borrow by raw-ptr

view details

csmoe

commit sha cd7b5edc2cac3fa0db6b464a6e94edd8f334274d

update test ui for raw-ptr borrow inside generator

view details

Tianjiao Huang

commit sha d336e593cc07139468c8f6f12b929e80ae365159

Fix invalid link to C++ Exception Handling ABI documentation

view details

Mazdak Farrokhzad

commit sha 93efe41b4ef9e0cccedbf962381002d48b3f780c

stabilize transparent_enums

view details

Mazdak Farrokhzad

commit sha 25460ebef6ae94494fc89a736a2f51bef2ea55c3

transparent_enums: test alignment

view details

Tomasz Miąsko

commit sha 6d218db26df424722d13db0ed3babae3cf450bb3

compiletest: Simplify multi-debugger support Previous implementation used a single mode type to store various pieces of otherwise loosely related information: * Whether debuginfo mode is in use or not. * Which debuggers should run in general. * Which debuggers are enabled for particular test case. The new implementation introduces a separation between those aspects. There is a single debuginfo mode parametrized by a debugger type. The debugger detection is performed first and a separate configuration is created for each detected debugger. The test cases are gathered independently for each debugger which makes it trivial to implement support for `ignore` / `only` conditions. Functional changes: * A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.). * Debugger name is included in the test name. * Test outputs are placed in per-debugger directory. * Fixed spurious hash mismatch. Previously, the config mode would change from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or `DebugInfoLldb` (when running them) which would affect hash computation. * PYTHONPATH is additionally included in gdb hash. * lldb-python and lldb-python-dir are additionally included in lldb hash.

view details

Guillaume Gomez

commit sha 6590339c31ab934add15ec49bc474ba9d78435e2

Clean up E0205 explanation

view details

Erin Power

commit sha c75a1f0e4dfd6e4a3929bc6496018734b5ef60c9

Update RELEASES.md for 1.41.0

view details

XAMPPRocky

commit sha 5918e9f02595a4b9ffacc4ecf5a0d470528a3824

Update RELEASES.md

view details

Esteban Küber

commit sha c775927d7fee06743631d138eac91a862c8f6faf

Suggest borrowing `Vec<NonCopy>` in for loop Partially address #64167.

view details

Aaron Hill

commit sha 4ee4287b1da13f56d063fa5b4234780def0d5af1

Account for non-types in substs for opaque type error messages Fixes #68368 Previously, I assumed that the substs contained only types, which caused the computed index number to be wrong.

view details

Guillaume Gomez

commit sha 94fcda0e1346f284c44a27c5c07c2b0999e5bc29

clean up E0214 explanation

view details

push time in 25 days

Pull request review commentrust-lang/blog.rust-lang.org

announce Cleanup Crew ICE-breaker group

+---+layout: post+title: "Announcing the Cleanup Crew ICE-breaker group"+author: Santiago Pastorino+description: "A new blog where the Rust team can post updates on the latest developments"+team: the compiler team <https://www.rust-lang.org/governance/teams/compiler>+---++Following Niko Matsakis' announcement of the [**LLVM ICE-breaker+group**](https://blog.rust-lang.org/inside-rust/2019/10/22/LLVM-ICE-breakers.html),+I'm pleased to announce the **Cleanup Crew ICE-breaker group**. It+follows the same principle, if you know Rust and would like to+contribute to rustc -- but without knowing about the compiler or taking+on a large commitment -- then the Cleanup Crew ICE-breaker group might+well be for you!++### What is the Cleanup Crew ICE-breaker group?++The "Cleanup Crew" are focused on improving bug reports. Specifically,+the goal is to try to ensure that every bug report has all the+information that will be needed for someone to fix it:++    - a minimal, standalone example that shows the problem+    - links to duplicates or related bugs+    - if the bug is a regression (something that used to work, but no+      longer does), then a bisection to the PR or nightly that caused+      the regression++This kind of cleanup is invaluable in getting bugs fixed.++### Who should join?++It can be done by anybody who knows Rust, without any particularly deep+knowledge of the compiler.  If you want to be part of it and be notified+about things to do, just [open a PR]! When we come across a suitable+bug, we'll write a message that `@`-mentions every Github user on that+team. If you have some time, maybe you can provide some useful+information.++[open a PR]: https://rust-lang.github.io/rustc-guide/ice-breaker/about.html#join

I've just followed the same idea of the LLVM ICE Breaker announcement but maybe isn't it better to just point to the PR?

spastorino

comment created time in a month

create barnchspastorino/blog.rust-lang.org

branch : announce-cleanup-crew

created branch time in a month

issue commentrust-lang/compiler-team

make a "Cleanup Crew" ICE-breakers for bisection

Configure the rust-lang/rust repository to support the ICE-breakers commands, similar to this Done: https://github.com/rust-lang/rust/pull/68581

Create a sample PR for adding yourself, similar to rust-lang/team#140 Done: https://github.com/rust-lang/team/pull/221

Link to the sample PR in this section of the rustc-guide Done: https://github.com/rust-lang/rustc-guide/pull/565

nikomatsakis

comment created time in a month

create barnchspastorino/rustc-guide

branch : example-pr-for-cleanup-crew

created branch time in a month

PR closed rust-lang/team

Add john-doe to Cleanup Crew ICE-breakers

This PR is meant to serve as an example! To add yourself to the Cleanup Crew ICE-breaker team, just create a commit like this one, but using your own username instead of john-doe.

If you are already a member of a Rust team you don't need to add a people/john-doe.toml like file because you will have an existing one for your username. If you're not part of the team, you have to checkout the repository, run the command below and commit the new file it creates

cargo run add-person $your_user_name
+4 -0

1 comment

2 changed files

spastorino

pr closed time in a month

pull request commentrust-lang/team

Add john-doe to Cleanup Crew ICE-breakers

(This PR is just meant to serve as an example, so I'm going to close it without merging.)

spastorino

comment created time in a month

PR opened rust-lang/team

Add john-doe to Cleanup Crew ICE-breakers

This PR is meant to serve as an example! To add yourself to the Cleanup Crew ICE-breaker team, just create a commit like this one, but using your own username instead of john-doe.

If you are already a member of a Rust team you don't need to add a people/john-doe.toml like file because you will have an existing one for your username. If you're not part of the team, you have to checkout the repository, run the command below and commit the new file it creates

cargo run add-person $your_user_name
+4 -0

0 comment

2 changed files

pr created time in a month

create barnchspastorino/team

branch : cleanupicebreaker-example

created branch time in a month

PR opened rust-lang/rust

Add support for icebreakers-cleanup-crew commands

r? @nikomatsakis

+11 -0

0 comment

1 changed file

pr created time in a month

create barnchspastorino/rust

branch : support-ice-breaker-cleanup-crew

created branch time in a month

Pull request review commentrust-lang/rust

don't clone types that are copy, round two.

 impl<'cx, 'tcx> MirBorrowckCtxt<'cx, 'tcx> {         // Check is_empty() first because it's the common case, and doing that         // way we avoid the clone() call.         if !self.access_place_error_reported.is_empty()-            && self.access_place_error_reported.contains(&(place_span.0.clone(), place_span.1))+            && self.access_place_error_reported.contains(&(*place_span.0, place_span.1))

Yeah, except in the cases @oli-obk mentions I'd change most of the uses to take Place by value. I need to do a bunch of cleanups still :).

matthiaskrgr

comment created time in a month

pull request commentrust-lang/rust

Add GitHub issue templates

Yeah it could be but it would need a special template because regressions are not necessarily ICEs. Maybe we can just have a regression template and do what you're saying from the tool.

XAMPPRocky

comment created time in a month

issue commentrust-lang/team

Working Group mailing list

Was also mentioning Pietro the following ...

Santiago Pastorino: hey Pietro
Santiago Pastorino: https://github.com/rust-lang/team/blob/master/teams/wg-leads.toml
Santiago Pastorino: I guess I know what the intention of this was
Santiago Pastorino: I guess we wanted to include all wg leads
Santiago Pastorino: but that's not what the thing do
Santiago Pastorino: given this https://github.com/rust-lang/team/blob/master/teams/wg-leads.toml#L7 it includes the leads
Santiago Pastorino: but this https://github.com/rust-lang/team/blob/master/teams/wg-leads.toml#L5 is empty
Santiago Pastorino: I think we want that group to be special and go over all the teams, find the ones that are wgs and find the leads of those
Santiago Pastorino: right?
XAMPPRocky

comment created time in a month

push eventrust-lang/compiler-team

Wesley Wiser

commit sha 462036aa775ef71ef88849642d0807ab830dd7d2

Add compiler team triage meeting notes for 2020-01-09

view details

Santiago Pastorino

commit sha 650b2b3e8a385ae639b0463046e41a355ebb1c11

Merge pull request #244 from rust-lang/wesleywiser-patch-4 Add compiler team triage meeting notes for 2020-01-09

view details

push time in a month

push eventrust-lang/compiler-team

Wesley Wiser

commit sha 34e9c1ed6f045dea9c61d05281997fcc18aa2e91

Add compiler team triage meeting notes for 2020-01-02

view details

Santiago Pastorino

commit sha 4295c4c34cb569fb914a84178b5ae6407f6e3721

Merge pull request #243 from rust-lang/wesleywiser-patch-3 Add compiler team triage meeting notes for 2020-01-02

view details

push time in a month

pull request commentrust-lang/rust

Add GitHub issue templates

@XAMPPRocky I was referring more to the output of the tool, that emits a report to be pasted on Github. Check this https://github.com/rust-lang/cargo-bisect-rustc/pull/41 out. You can check how the report looks here https://github.com/spastorino/cargo-bisect-sample/issues/1. I'm wondering if we can connect in some way that report with this templates but as the very minimum we should use the same format. Probably yours is better :).

XAMPPRocky

comment created time in a month

Pull request review commentrust-lang/rust

Local is copy

 impl<'tcx> Place<'tcx> {     pub fn local_or_deref_local(&self) -> Option<Local> {         match self.as_ref() {             PlaceRef { local, projection: &[] }-            | PlaceRef { local, projection: &[ProjectionElem::Deref] } => Some(*local),+            | PlaceRef { local, projection: &[ProjectionElem::Deref] } => Some(local),

Fixed.

spastorino

comment created time in a month

push eventspastorino/rust

Santiago Pastorino

commit sha 3859a474a1cdec18c6b971c947a77a3af26b43df

Remove unneeded & on match pattern

view details

push time in a month

Pull request review commentrust-lang/rust

Local is copy

 rustc_index::newtype_index! {  #[derive(Clone, Copy, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)] pub struct PlaceRef<'a, 'tcx> {-    pub local: &'a Local,+    pub local: Local,     pub projection: &'a [PlaceElem<'tcx>],

Unsure, I just did it to try out and I'm getting ...

error[E0597]: `deref` does not live long enough
    --> src/librustc_mir/borrow_check/mod.rs:1400:41
     |
855  |   impl<'cx, 'tcx> MirBorrowckCtxt<'cx, 'tcx> {
     |             ---- lifetime `'tcx` defined here
...
1400 |                   root_place.projection = &deref;
     |                                           ^^^^^^ borrowed value does not live long enough
...
1413 |           if places_conflict::borrow_conflicts_with_place(
     |  ____________-
1414 | |             self.infcx.tcx,
1415 | |             &self.body,
1416 | |             place,
...    |
1420 | |             places_conflict::PlaceConflictBias::Overlap,
1421 | |         ) {
     | |_________- argument requires that `deref` is borrowed for `'tcx`
...
1433 |       }
     |       - `deref` dropped here while still borrowed

error[E0621]: explicit lifetime required in the type of `issued_borrow`
   --> src/librustc_mir/borrow_check/diagnostics/conflict_errors.rs:547:9
    |
344 |         issued_borrow: &BorrowData<'tcx>,
    |                        ----------------- help: add explicit lifetime `'cx` to the type of `issued_borrow`: `&'cx borrow_check::borrow_set::BorrowData<'tcx>`
...
547 |         err
    |         ^^^ lifetime `'cx` required

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0597, E0621.
For more information about an error, try `rustc --explain E0597`.
error: could not compile `rustc_mir`.

To learn more, run the command again with --verbose.

Didn't pay a lot of attention to be honest, should I fix this in this PR and investigate on a different one?.

spastorino

comment created time in a month

push eventspastorino/rust

Santiago Pastorino

commit sha afe992832693f5712b14cba406eced8b4d1f04b1

./x.py fmt

view details

push time in a month

Pull request review commentrust-lang/rust

Local is copy

 impl<Bx: BuilderMethods<'a, 'tcx>> LocalAnalyzer<'mir, 'a, 'tcx, Bx> {                     // We use `NonUseContext::VarDebugInfo` for the base,                     // which might not force the base local to memory,                     // so we have to do it manually.-                    self.visit_local(place_ref.local, context, location);+                    self.visit_local(&place_ref.local, context, location);

This should also take a Local instead of &Local but I'd leave that for a deeper change related to visitors.

spastorino

comment created time in a month

PR opened rust-lang/rust

Local is copy

r? @oli-obk

+122 -122

0 comment

31 changed files

pr created time in a month

create barnchspastorino/rust

branch : local-is-copy

created branch time in a month

pull request commentrust-lang/rust

Add GitHub issue templates

@XAMPPRocky I like this idea, I wonder if we can make https://github.com/rust-lang/cargo-bisect-rustc adhere better to this or we can use here and there the same format.

XAMPPRocky

comment created time in a month

pull request commentrust-lang/compiler-team

Create major_change issue template

I at least find #t-compiler a bit..."full"

I have the feeling that as much as we can group things from #t-compiler into #t-compiler/category the better.

oli-obk

comment created time in a month

push eventrust-lang/compiler-team

Wesley Wiser

commit sha 9e64c6e693e669cca739c27700b701f708a7fc43

Add notes for compiler team triage meeting on 2020-01-23

view details

Santiago Pastorino

commit sha cb4f2d51a3d27c619d91ee18da543baedc13af83

Merge pull request #241 from rust-lang/wesleywiser-patch-2 Add notes for compiler team triage meeting on 2020-01-23

view details

push time in a month

push eventrust-lang/compiler-team

Wesley Wiser

commit sha c45492c2ced3f2e35a1203f00c488478f586df34

Add compiler team triage meeting notes for 2019-12-19

view details

Santiago Pastorino

commit sha 8146dbc5c1dcc2cfe9a603c4595ee5c1831a43f5

Merge pull request #240 from rust-lang/wesleywiser-patch-1 Add compiler team triage meeting notes for 2019-12-19

view details

push time in a month

pull request commentrust-lang/rustc-guide

add cleanup crew

Looks good to me now, maybe as @lqd mentioned in one case, we should link all the streams that show up there.

nikomatsakis

comment created time in a month

pull request commentrust-lang/rustc-guide

add cleanup crew

@nikomatsakis this is great, left a comment about the last section.

nikomatsakis

comment created time in a month

Pull request review commentrust-lang/rustc-guide

add cleanup crew

+# Cleanup Crew++**Github Label:** [ICEBreaker-Cleanup-Crew]++[ICEBreaker-Cleanup-Crew]: https://github.com/rust-lang/rust/labels/ICEBreaker-Cleanup-Crew++The "Cleanup Crew" are focused on improving bug reports. Specifically,+the goal is to try to ensure that every bug report has all the+information that will be needed for someone to fix it:++* a minimal, standalone example that shows the problem+* links to duplicates or related bugs+* if the bug is a regression (something that used to work, but no longer does),+  then a bisection to the PR or nightly that caused the regression++This kind of cleanup is invaluable in getting bugs fixed. Better+still, it can be done by anybody who knows Rust, without any+particularly deep knowledge of the compiler.++Let's look a bit at the workflow for doing "cleanup crew" actions.++## Finding a minimal, standalone example++Here the ultimate goal is to produce an example that reproduces the same+problem but without relying on any external crates. Such a test ought to contain+as little code as possible, as well. This will make it much easier to isolate the problem.++However, even if the "ultimate minimal test" cannot be achieved, it's+still useful to post incremental minimizations. For example, if you+can eliminate some of the external dependencies, that is helpful, and+so forth. ++It's particularly useful to reduce to an example that works+in the [Rust playground](https://play.rust-lang.org/), rather than+requiring people to checkout a cargo build.++There are many resources for how to produce minimized test cases. Here+are a few:++* The [rust-reduce](https://github.com/jethrogb/rust-reduce) tool can try to reduce+  code automatically.+  * The [C-reduce](https://embed.cs.utah.edu/creduce/) tool also works+    on Rust code, though it requires that you start from a single+    file. (XXX link to some post explaining how to do it?)+* pnkfelix's [Rust Bug Minimization Patterns] blog post+  * This post focuses on "heavy bore" techniques, where you are+    starting with a large, complex cargo project that you wish to+    narrow down to something standalone.++[Rust Bug Minimization Patterns]: http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/++## Links to duplicate or related bugs++If you are on the "Cleanup Crew", you will sometimes see multiple bug+reports that seem very similar. You can link one to the other just by+mentioning the other bug number in a Github comment. Sometimes it is+useful to close duplicate bugs. But if you do so, you should always+copy any test case from the bug you are closing to the other bug that+remains open, as sometimes duplicate-looking bugs will expose+different facets of the same problem.++## Bisecting regressions++For regressions (something that used to work, but no longer does), it+is super useful if we can figure out precisely when the code stopped+working.  The gold standard is to be able to identify the precise+**PR** that broke the code, so we can ping the author, but even+narrowing it down to a nightly build is helpful, especially as that+then gives us a range of PRs. (One other challenge is that we+sometimes land "rollup" PRs, which combine multiple PRs into one.)++### cargo-bisect-rustc++To help in figuring out the cause of a regression we have a tool+called [cargo-bisect-rustc]. It will automatically download and test+various builds of rustc. For recent regressions, it is even able to+use the builds from our CI to track down the regression to a specific+PR; for older regressions, it will simply identify a nightly.++To learn to use [cargo-bisect-rustc], check out [this blog+post][learn], which gives a quick introduction to how it works. You+can also ask questions at the Zulip stream+`#t-compiler/cargo-bisect-rustc`, or help in improving the tool.++[cargo-bisect-rustc]: https://github.com/rust-lang/cargo-bisect-rustc/+[learn]: https://blog.rust-lang.org/inside-rust/2019/12/18/bisecting-rust-compiler.html++### identifying the range of PRs in a nightly++If you've managed to narrow things down to a particular nightly build,+it is then helpful if we can identify the set of PRs that this+corresponds to. One helpful command in that regard is `rustc +nightly+-vV`, which will cause it to output a number of useful bits of version+info, including the `commit-hash`. Given the commit-hash of two+nightly versions, you can find all of PRs that have landed in between+by taking the following steps:++1. Go to an update checkout of the [rust-lang/rust] repository+2. Execute the command `git log --author=bors --format=oneline SHA1..SHA2`+  * This will list out all of the commits by bors, which is our merge bot+  * Each commit corresponds to one PR, and information about the PR should be in the description+3. Copy and paste that information into the bug report++Often, just eye-balling the PR descriptions (which are included in the+commit messages) will give you a good idea which one likely caused the+problem. But if you're unsure feel free to just ping the compiler team+(`@rust-lang/compiler`) or else to ping the authors of the PR+themselves.

I'm not sure about this section, or at least is not clear to me why you're not relying on cargo-bisect-rustc for this case too. Is this for the case where the artifacts related to those PRs are not around anymore?.

nikomatsakis

comment created time in a month

Pull request review commentrust-lang/rustc-guide

add cleanup crew

+# Cleanup Crew++**Github Label:** [ICEBreaker-Cleanup-Crew]++[ICEBreaker-Cleanup-Crew]: https://github.com/rust-lang/rust/labels/ICEBreaker-Cleanup-Crew++The "Cleanup Crew" are focused on improving bug reports. Specifically,+the goal is to try to ensure that every bug report has all the+information that will be needed for someone to fix it:++* a minimal, standalone example that shows the problem+* links to duplicates or related bugs+* if the bug is a regression (something that used to work, but no longer does),+  then a bisection to the PR or nightly that caused the regression++This kind of cleanup is invaluable in getting bugs fixed. Better+still, it can be done by anybody who knows Rust, without any+particularly deep knowledge of the compiler.++Let's look a bit at the workflow for doing "cleanup crew" actions.++## Finding a minimal, standalone example++Here the ultimate goal is to produce an example that reproduces the same+problem but without relying on any external crates. Such a test ought to contain+as little code as possible, as well. This will make it much easier to isolate the problem.++However, even if the "ultimate minimal test" cannot be achieved, it's+still useful to post incremental minimizations. For example, if you+can eliminate some of the external dependencies, that is helpful, and+so forth. ++It's particularly useful to reduce to an example that works+in the [Rust playground](https://play.rust-lang.org/), rather than+requiring people to checkout a cargo build.++There are many resources for how to produce minimized test cases. Here+are a few:++* The [rust-reduce](https://github.com/jethrogb/rust-reduce) tool can try to reduce+  code automatically.+  * The [C-reduce](https://embed.cs.utah.edu/creduce/) tool also works+    on Rust code, though it requires that you start from a single+    file. (XXX link to some post explaining how to do it?)+* pnkfelix's [Rust Bug Minimization Patterns] blog post+  * This post focuses on "heavy bore" techniques, where you are+    starting with a large, complex cargo project that you wish to+    narrow down to something standalone.++[Rust Bug Minimization Patterns]: http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/++## Links to duplicate or related bugs++If you are on the "Cleanup Crew", you will sometimes see multiple bug+reports that seem very similar. You can link one to the other just by+mentioning the other bug number in a Github comment. Sometimes it is+useful to close duplicate bugs. But if you do so, you should always+copy any test case from the bug you are closing to the other bug that+remains open, as sometimes duplicate-looking bugs will expose+different facets of the same problem.++## Bisecting regressions++For regressions (something that used to work, but no longer does), it+is super useful if we can figure out precisely when the code stopped+working.  The gold standard is to be able to identify the precise+**PR** that broke the code, so we can ping the author, but even+narrowing it down to a nightly build is helpful, especially as that+then gives us a range of PRs. (One other challenge is that we+sometimes land "rollup" PRs, which combine multiple PRs into one.)++### cargo-bisect-rustc++To help in figuring out the cause of a regression we have a tool+called [cargo-bisect-rustc]. It will automatically download and test+various builds of rustc. For recent regressions, it is even able to+use the builds from our CI to track down the regression to a specific+PR; for older regressions, it will simply identify a nightly.++To learn to use [cargo-bisect-rustc], check out [this blog+post][learn], which gives a quick introduction to how it works. You+can also ask questions at the Zulip stream+`#t-compiler/cargo-bisect-rustc`, or help in improving the tool.

Started reading this and I thought, I'm going to comment that we should mention the stream :smile:. This is brilliant.

nikomatsakis

comment created time in a month

issue commentrust-lang/rustc-guide

Commit copies of papers?

Saw we have an exclude attribute on linkchecker, maybe we can change it with warn and make all the checks to those that fail give us a warning.

mark-i-m

comment created time in a month

issue commentrust-lang/rustc-guide

Commit copies of papers?

Can't we tag certain links and have them giving warnings instead of hard errors?. So most of the links will fail in the situations described but we can tag links to papers in the ones we consider fragile in some way and have our system just giving warnings.

mark-i-m

comment created time in a month

issue commentrust-lang/rustc-guide

Document setup of rust-analyzer specifically for rustc hacking atop "popular" IDE/editors

https://github.com/prabirshrestha/vim-lsp seem to be one of the most popular ones. Maybe targeting just that one or two would suffice for vim?.

pnkfelix

comment created time in a month

pull request commentrust-lang/compiler-team

Create major_change issue template

cc @nikomatsakis for final decision

oli-obk

comment created time in a month

push eventrust-lang/compiler-team

Wesley Wiser

commit sha e498def1a84b8acdc20484a35ab4dc9780869e16

Add notes for compiler team triage meeting on 2019-12-12

view details

Santiago Pastorino

commit sha 8e622342330b13edc01882647c6ad3d213e623c6

Merge pull request #238 from rust-lang/wesleywiser-patch-1 Add notes for compiler team triage meeting on 2019-12-12

view details

push time in a month

push eventrust-lang/compiler-team

Aleksey Kladov

commit sha f4c3704bf0a156bbc35a8446991b06848188db56

Fix the link to the procedure in the template

view details

Santiago Pastorino

commit sha 31807bcc92d0822a7f77f7afd343e2e595967997

Merge pull request #236 from rust-lang/Fix-issue-template Fix the link to the procedure in the template

view details

push time in a month

more