Stream: t-compiler

Topic: #54818 weekly meeting 2018-11-08


pnkfelix (Nov 08 2018 at 14:11, on Zulip):

hi @T-compiler ; we'll be having our weekly meeting here in about 50 minutes.

pnkfelix (Nov 08 2018 at 14:11, on Zulip):

In the meantime, I'm going do some eager triaging of issues and whatnot (as to save time in the meeting itself), and I'll try to post statements here summarizing my actions as I do that.

pnkfelix (Nov 08 2018 at 14:13, on Zulip):

I'm going through the P-high issues first, as usual.

pnkfelix (Nov 08 2018 at 14:13, on Zulip):

first one is "NLL error on closure, but not on equivalent function" #55526

pnkfelix (Nov 08 2018 at 14:15, on Zulip):

I tagged this as P-high recently (2 days ago). I don't think the @WG-compiler-nll team looked at it during our meeting (because there are higher priority items). But I think I should have some time to look at it tomorrow or Monday, so I'll assign it to myself for now.

pnkfelix (Nov 08 2018 at 14:15, on Zulip):

the next one is also NLL: "nll: respect user type annotations with constants in patterns" #55511

pnkfelix (Nov 08 2018 at 14:16, on Zulip):

I'll assign that to myself as well. If I don't get to these things by Monday, then I'll unassign myself and hopefully someone from the NLL team will pick it up at the NLL meeting this coming Tuesday.

pnkfelix (Nov 08 2018 at 14:17, on Zulip):

next: "regression: stack overflow on macosx with xcode 6.4" #55471

pnkfelix (Nov 08 2018 at 14:17, on Zulip):

this was discussed last week. It looks like @Oli has been working hard on it, as one can see from PR #55617

pnkfelix (Nov 08 2018 at 14:19, on Zulip):

next: "ICE when running cargo doc on typenum at librustc/traits/structural_impls.rs:178" #52873

pnkfelix (Nov 08 2018 at 14:20, on Zulip):

Hmm. the main thing of interest here is whether we had a process failure of some sort, in that we didn't backport this back when it landed on Sep 26th.

pnkfelix (Nov 08 2018 at 14:21, on Zulip):

Seems like its a classic case of a PR being tagged a Fixes #XXXXand then bors closes the thing tagged as it fixing.

pnkfelix (Nov 08 2018 at 14:22, on Zulip):

but you know, the right thing may be to just make bors smart enough to not automatically close issues tagged as stable-to-stable or stable-to-beta regressions?

pnkfelix (Nov 08 2018 at 14:22, on Zulip):

that seems like it would help mitigate issues like this.

pnkfelix (Nov 08 2018 at 14:28, on Zulip):

I wrote some notes on the issue. And now I think I'll go file a bug ... on the homu repo, I think...

varkor (Nov 08 2018 at 14:34, on Zulip):

Fixes #XXX is a GitHub thing, not a bors thing.

varkor (Nov 08 2018 at 14:34, on Zulip):

I don't think there's a way to change it, but you could look in the repository settings.

varkor (Nov 08 2018 at 14:34, on Zulip):

I suppose bors could automatically reopen such issues though.

pnkfelix (Nov 08 2018 at 14:37, on Zulip):

Oh for some reason I thought it was a bors thing, because I thought I saw notifications that bors was the one closing the issue

pnkfelix (Nov 08 2018 at 14:37, on Zulip):

I see, I'm misinterpreting the message " bors closed this in #54199 on Sep 26"

blitzerr (Nov 08 2018 at 14:37, on Zulip):

:wave:

pnkfelix (Nov 08 2018 at 14:38, on Zulip):

i.e. github is presenting it as an action being directly taken by bors, but its really just a side-effect of bors having authored that commit

varkor (Nov 08 2018 at 14:38, on Zulip):

yeah

pnkfelix (Nov 08 2018 at 14:40, on Zulip):

okay. Well, that's all the P-high issues.

pnkfelix (Nov 08 2018 at 14:41, on Zulip):

next up... well #54818's agenda said RC2 milestone, but I just fixed that to now say Release milestone

pnkfelix (Nov 08 2018 at 14:42, on Zulip):

there's a lot of items on here

pnkfelix (Nov 08 2018 at 14:42, on Zulip):

most of them are NLL.

pnkfelix (Nov 08 2018 at 14:43, on Zulip):

I'm going to first go through the ones tagged as NLL-deferred and determine whether they should be removed from the Release Milestone

pnkfelix (Nov 08 2018 at 14:43, on Zulip):

starting from the bottom (again, just NLL-deferred things)...

pnkfelix (Nov 08 2018 at 14:43, on Zulip):

"two-phase-borrows need a specification" #46901

pnkfelix (Nov 08 2018 at 14:44, on Zulip):

niko's the one who put this on the release milestone, back in July

pnkfelix (Nov 08 2018 at 14:44, on Zulip):

I can't imagine this would actually block a release though

pnkfelix (Nov 08 2018 at 14:45, on Zulip):

I'm going to take it off the milestone, and put an I-nominated tag on it for discussion at next NLL meeting.

nagisa (Nov 08 2018 at 14:45, on Zulip):

@pnkfelix wrt milestone, last meeting @nikomatsakis said that those issues ought to be triaged'n'stuff between you and niko

pnkfelix (Nov 08 2018 at 14:45, on Zulip):

right

nagisa (Nov 08 2018 at 14:45, on Zulip):

but they are not anything resembling blockers

pnkfelix (Nov 08 2018 at 14:46, on Zulip):

I just figured I'll note it here as I change them.

pnkfelix (Nov 08 2018 at 14:46, on Zulip):

I suppose I could do this in an NLL stream instead.

pnkfelix (Nov 08 2018 at 14:46, on Zulip):

Okay I'll do that, move this part of my running narrative to WG-compiler-nll stream

pnkfelix (Nov 08 2018 at 15:02, on Zulip):

okay, well I didn't make quite as much progress on that as I had hoped

pnkfelix (Nov 08 2018 at 15:02, on Zulip):

oh well

pnkfelix (Nov 08 2018 at 15:02, on Zulip):

Hi @T-compiler ! :smile:

pnkfelix (Nov 08 2018 at 15:02, on Zulip):

(btw if people would prefer that I put the pre-meeting notes like the ones I had above on a different topic, just say so...)

pnkfelix (Nov 08 2018 at 15:03, on Zulip):

I already pre-triaged the P-high issues, as noted above.

mw (Nov 08 2018 at 15:03, on Zulip):

Thanks, Felix!

pnkfelix (Nov 08 2018 at 15:03, on Zulip):

It isn't much of an accomplishment, given that there were only four of them...

pnkfelix (Nov 08 2018 at 15:04, on Zulip):

Anyway next up is issues tagged for the 2018 Release. I suggest that we skip all the ones tagged NLL, and focus on just the others (that is,the non-NLL ones that are also relevant to T-compiler)

pnkfelix (Nov 08 2018 at 15:05, on Zulip):

which basically means we're looking at something like this

pnkfelix (Nov 08 2018 at 15:05, on Zulip):

(four issues, yay!)

pnkfelix (Nov 08 2018 at 15:05, on Zulip):

first up, "Tracking issue for RFC 2388, reserve the try keyword and resolve do catch { .. } syntax question with try { .. }" #50412

pnkfelix (Nov 08 2018 at 15:06, on Zulip):

it seems like progress here has stalled

pnkfelix (Nov 08 2018 at 15:06, on Zulip):

which may be in part due to this issue being tagged with both T-lang and T-compiler

pnkfelix (Nov 08 2018 at 15:06, on Zulip):

I'll make a note saying as much

pnkfelix (Nov 08 2018 at 15:07, on Zulip):

next: "rewrite ... to ..= as an idiom lint for Rust 2018 edition" #51043

pnkfelix (Nov 08 2018 at 15:08, on Zulip):

it seems like this is also stalled, and perhaps blocked on some pattern-parentheses feature

pnkfelix (Nov 08 2018 at 15:09, on Zulip):

Would anyone like to take ownership of this? It seems like it might be a relatively easy way to get one's feet with ... stuff in the compiler ...

varkor (Nov 08 2018 at 15:09, on Zulip):

pattern-parentheses has been stabilised, hasn't it?

pnkfelix (Nov 08 2018 at 15:09, on Zulip):

/me does not know

varkor (Nov 08 2018 at 15:10, on Zulip):

so this should just be changing the "maybe applicable" lint to "applicable"

varkor (Nov 08 2018 at 15:10, on Zulip):

(stabilised here: https://github.com/rust-lang/rust/issues/51087)

pnkfelix (Nov 08 2018 at 15:10, on Zulip):

I'm going t tag this as P-high

pnkfelix (Nov 08 2018 at 15:10, on Zulip):

and the previous issue too

varkor (Nov 08 2018 at 15:11, on Zulip):

I'm happy to take this, anyway — it should be a very quick fix

varkor (Nov 08 2018 at 15:11, on Zulip):

(or I could mentor it if it's not too time sensitive)

pnkfelix (Nov 08 2018 at 15:11, on Zulip):

Okay greaT!

pnkfelix (Nov 08 2018 at 15:12, on Zulip):

next: "[Rust 2018] rustdoc doesn't link "pub use whatever_crate;"" #52509

pnkfelix (Nov 08 2018 at 15:12, on Zulip):

I had agree to help with this and then it fell off my radar

pnkfelix (Nov 08 2018 at 15:12, on Zulip):

probably because it is not tagged with a P- label

pnkfelix (Nov 08 2018 at 15:13, on Zulip):

next: "Rustc does not warn about use with paths incompatible with uniform_paths for edition 2018" #53797

pnkfelix (Nov 08 2018 at 15:13, on Zulip):

(oh: re #52509: I tagged as P-high and left it assigned to self)

pnkfelix (Nov 08 2018 at 15:14, on Zulip):

so, for #53797 ... this was closed and then reopened three weeks ago

pnkfelix (Nov 08 2018 at 15:14, on Zulip):

@Vadim Petrochenkov removed their assignment two weeks ago ...

pnkfelix (Nov 08 2018 at 15:16, on Zulip):

its being discussed at #53797 uniform path ambiguity topic on zulip

pnkfelix (Nov 08 2018 at 15:16, on Zulip):

but last discussion there was, I think, October 18th...

pnkfelix (Nov 08 2018 at 15:16, on Zulip):

I have to assume that since this is on the Release milestone, it needs to be tagged as P-high

pnkfelix (Nov 08 2018 at 15:16, on Zulip):

is anyone present willing to take ownership of this?

pnkfelix (Nov 08 2018 at 15:17, on Zulip):

(its assigned to eddyb but I'm not clear on whether they still own it)

varkor (Nov 08 2018 at 15:17, on Zulip):

cc @eddyb

pnkfelix (Nov 08 2018 at 15:18, on Zulip):

okay well i'm not going to stall on this right now

pnkfelix (Nov 08 2018 at 15:18, on Zulip):

next up are the beta-nominations

pnkfelix (Nov 08 2018 at 15:19, on Zulip):

first "Check for negative impls when finding auto traits" #55356

pnkfelix (Nov 08 2018 at 15:20, on Zulip):

hmm still awaiting review from niko

nagisa (Nov 08 2018 at 15:20, on Zulip):

I do like tiny and well tested beta-nominated patches :P

pnkfelix (Nov 08 2018 at 15:21, on Zulip):

is there anyone else comforatable reviewing trait selection stuff?

pnkfelix (Nov 08 2018 at 15:21, on Zulip):

i only ask becasue I'd love to take this off niko's plate if we can

mw (Nov 08 2018 at 15:21, on Zulip):

@eddyb? @Ariel Ben-Yehuda ?

pnkfelix (Nov 08 2018 at 15:22, on Zulip):

okay well I guess we leave it

pnkfelix (Nov 08 2018 at 15:22, on Zulip):

(I am tempted to go along with @nagisa and just tag it beta-accepted. But lets see if niko gets around to the review before next weeks' mtg)

pnkfelix (Nov 08 2018 at 15:23, on Zulip):

next: "rustbuild: use configured linker to build boostrap" #55378

pnkfelix (Nov 08 2018 at 15:23, on Zulip):

(sic)

pnkfelix (Nov 08 2018 at 15:23, on Zulip):

I ... don't care?

pnkfelix (Nov 08 2018 at 15:24, on Zulip):

as in, I wouldn't veto this being beta-accepted

mw (Nov 08 2018 at 15:24, on Zulip):

seems fine

pnkfelix (Nov 08 2018 at 15:24, on Zulip):

and I guess if it actually causes problems, we'll likely find out very quickly...

mw (Nov 08 2018 at 15:24, on Zulip):

although this is only visible to people building rustc

pnkfelix (Nov 08 2018 at 15:25, on Zulip):

still might matter to things like debian where they need to do builds, no?

mw (Nov 08 2018 at 15:25, on Zulip):

o well, the op asked specifically for it being backported

mw (Nov 08 2018 at 15:25, on Zulip):

yeah, I'm fine with backporting

pnkfelix (Nov 08 2018 at 15:26, on Zulip):

It is an interesting question about whether we should or should not backport such cases, in terms of which audience we optimize for

pnkfelix (Nov 08 2018 at 15:26, on Zulip):

but for now I say "lets backport" and wait for someone else to yell at me about it.

pnkfelix (Nov 08 2018 at 15:26, on Zulip):

next: "resolve: Filter away macro prelude in modules with #[no_implicit_prelude] on 2018 edition" #55630

pnkfelix (Nov 08 2018 at 15:26, on Zulip):

oh wait that's T-lang

pnkfelix (Nov 08 2018 at 15:27, on Zulip):

finally: " Do not attempt to ascribe projections out of a ty var" #55637

pnkfelix (Nov 08 2018 at 15:28, on Zulip):

This is fixing a stable-to-beta regression. (An ICE from NLL migration.)

pnkfelix (Nov 08 2018 at 15:28, on Zulip):

I authored it so I don't want to just accept it without giving people a chance to object. :smile:

nagisa (Nov 08 2018 at 15:28, on Zulip):

we observed that it could cause problems if you have repeated type variables, e.g., type Foo<T> = (T, T) and an annotation like Foo<_>

nagisa (Nov 08 2018 at 15:29, on Zulip):

what problems

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

well

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

its more hypothetical at the moment

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

I filed the followup issue

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

to invetigate that question

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

"NLL: investigate ascription when a _ wildcard tyvar is repeated" #55748

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

the main issue is whether someone's type ascription that includes a lifetime

pnkfelix (Nov 08 2018 at 15:29, on Zulip):

could be potentially ignored by NLL

pnkfelix (Nov 08 2018 at 15:30, on Zulip):

in the sense that if they ascribe a lifetime that is not actually required by the borrow-checker, we might accept code

pnkfelix (Nov 08 2018 at 15:30, on Zulip):

that the developer had intended to be rejected

nagisa (Nov 08 2018 at 15:31, on Zulip):

I won’t object to the backport.

pnkfelix (Nov 08 2018 at 15:31, on Zulip):

(because of e.g. an unsafe block that assumes that the aforementioned type-ascription with a lifetime in it is actually being checked)

pnkfelix (Nov 08 2018 at 15:31, on Zulip):

I should probably tag #55748 with the Release milestone

nagisa (Nov 08 2018 at 15:31, on Zulip):

but it is not a "lets definitely do it!”.

pnkfelix (Nov 08 2018 at 15:31, on Zulip):

just in terms of getting an answer to whether its a problem

nagisa (Nov 08 2018 at 15:31, on Zulip):

i.e. not an obvious one.

pnkfelix (Nov 08 2018 at 15:31, on Zulip):

well, the alternative is to ICE on correct code

nagisa (Nov 08 2018 at 15:32, on Zulip):

yeah, that’s why I’m not objecting :slight_smile:

pnkfelix (Nov 08 2018 at 15:32, on Zulip):

okay

pnkfelix (Nov 08 2018 at 15:34, on Zulip):

okay that's all the beta nominations

pnkfelix (Nov 08 2018 at 15:34, on Zulip):

there are no stable-nominations

pnkfelix (Nov 08 2018 at 15:35, on Zulip):

next up, the stable-to-beta regressions (all of them, not just T-compiler)...

pnkfelix (Nov 08 2018 at 15:35, on Zulip):

we've discussed "[1.30 beta] Compiler hangs when compiling primal crate for armv7-apple-ios" #54627 a bunch of times already

pnkfelix (Nov 08 2018 at 15:36, on Zulip):

its been tagged as wontfix so i'll just move along

nagisa (Nov 08 2018 at 15:36, on Zulip):

And so we have the stack overflow, leaving 3 issues to look at

pnkfelix (Nov 08 2018 at 15:36, on Zulip):

next is "Rustc panics on nightly with crate interpolate" #54654, which I've requested more info on but gotten no response

pnkfelix (Nov 08 2018 at 15:37, on Zulip):

we already discussed "ICE: librustc/mir/tcx.rs:68: extracting field of non-tuple non-adt: Ty { ty: _ }" #55552 too

pnkfelix (Nov 08 2018 at 15:37, on Zulip):

so I think the only thing to look at is "Lifetimes bug on beta 1.31: the associated type may not live long enough" #55756

nikomatsakis (Nov 08 2018 at 15:37, on Zulip):

first "Check for negative impls when finding auto traits" #55356

I'll make a point of reviewing it

pnkfelix (Nov 08 2018 at 15:37, on Zulip):

#55756 is tagged as NLL-fixed-by-NLL

pnkfelix (Nov 08 2018 at 15:38, on Zulip):

except I don't understand the "Same holds for beta now except nll isn't quite there yet." note

pnkfelix (Nov 08 2018 at 15:38, on Zulip):

NLL should be turned on in the current beta...

nagisa (Nov 08 2018 at 15:38, on Zulip):

perhaps this bug is related to the migration mode?

pnkfelix (Nov 08 2018 at 15:38, on Zulip):

I'll assign this to myself to at least get clarity on tahat

nagisa (Nov 08 2018 at 15:38, on Zulip):

I believe that’s what we have enabled in the beta, and not "full" NLL

pnkfelix (Nov 08 2018 at 15:39, on Zulip):

yes, it could be ...

pnkfelix (Nov 08 2018 at 15:39, on Zulip):

but I would be surprised

pnkfelix (Nov 08 2018 at 15:39, on Zulip):

(not that migration mode is perfect or anything; but the particulars of this bug don't sound like a migration issue.)

pnkfelix (Nov 08 2018 at 15:39, on Zulip):

anyway, I'll assign to myself and mark P-high

nikomatsakis (Nov 08 2018 at 15:40, on Zulip):

NLL should be turned on in the current beta...

only in 2018 edition maybe?

pnkfelix (Nov 08 2018 at 15:40, on Zulip):

@nikomatsakis oh good point

pnkfelix (Nov 08 2018 at 15:40, on Zulip):

(So we should advise the bug filer to port their code to 2018 edition. :wink: )

pnkfelix (Nov 08 2018 at 15:41, on Zulip):

that's all the relevant stable-to-beta regressions

pnkfelix (Nov 08 2018 at 15:41, on Zulip):

and there are no stable-to-nightly regressions currently filed

pnkfelix (Nov 08 2018 at 15:41, on Zulip):

next, waiting-on-team

pnkfelix (Nov 08 2018 at 15:42, on Zulip):

still has "Support for the program data address space option of LLVM's Target Datalayout" #54993

Zack M. Davis (Nov 08 2018 at 15:42, on Zulip):

good morning @varkor https://github.com/rust-lang/rust/issues/51043 (..= suggestion stabilization) has been on my personal to-do list, and I fear I just hadn't found time yet)

pnkfelix (Nov 08 2018 at 15:42, on Zulip):

but that's been r+ed by eddyb

pnkfelix (Nov 08 2018 at 15:43, on Zulip):

wrote a note

pnkfelix (Nov 08 2018 at 15:43, on Zulip):

next up, I-nominated T-compiler

pnkfelix (Nov 08 2018 at 15:44, on Zulip):

there are four issues. Two are for the NLL team

varkor (Nov 08 2018 at 15:44, on Zulip):

@Zack M. Davis: are you happy having it taken off your hands, or would you prefer to get to it yourself?

pnkfelix (Nov 08 2018 at 15:44, on Zulip):

so I'll skip those (I nominated them earlier today for the NLL meeting)

pnkfelix (Nov 08 2018 at 15:45, on Zulip):

(FYI @Zack M. Davis and @varkor you may want to consider branching off into a separate topic)

pnkfelix (Nov 08 2018 at 15:45, on Zulip):

okay, so, the two nominated issues for us

pnkfelix (Nov 08 2018 at 15:45, on Zulip):

first is "Building diesel documentation fails" #54524

pnkfelix (Nov 08 2018 at 15:46, on Zulip):

this has a PR

pnkfelix (Nov 08 2018 at 15:47, on Zulip):

removed nominated tag and added P-high

pnkfelix (Nov 08 2018 at 15:47, on Zulip):

next up: "test suite: ERROR and WARN annotations are not mandatory in UI tests" #55596

pnkfelix (Nov 08 2018 at 15:47, on Zulip):

so, I nominated this

pnkfelix (Nov 08 2018 at 15:48, on Zulip):

@Vadim Petrochenkov is pointing out here that the ui test suite system does not require every test to include the //~ ERROR and //~ WARN annotations

pnkfelix (Nov 08 2018 at 15:48, on Zulip):

The fact it doesn't require them in all cases is, to my knowledge, by design

pnkfelix (Nov 08 2018 at 15:48, on Zulip):

the fact however, that it completely fails to check //~ WARN annotations is not be design

pnkfelix (Nov 08 2018 at 15:49, on Zulip):

(that I have filed as a separate bug, "compiletest does not signal when a ui (or compile-fail) test with //~ WARN gets unexpected warnings" #55693

pnkfelix (Nov 08 2018 at 15:49, on Zulip):

the reason I nominated #55596 is because I wanted to discuss the fundamental policy we would follow

pnkfelix (Nov 08 2018 at 15:49, on Zulip):

1. Do we want to require every ui test to include every necessary //~ ERROR annotation

mw (Nov 08 2018 at 15:49, on Zulip):

so tests without ERROR or WARN annotations are just ignored?

pnkfelix (Nov 08 2018 at 15:50, on Zulip):

well, it still checks their .stderr file for diff, of course

nagisa (Nov 08 2018 at 15:50, on Zulip):

I think the point is that errors and warnings from tests are not properly checked

pnkfelix (Nov 08 2018 at 15:50, on Zulip):

but if your test has no //~ ERROR annoations

pnkfelix (Nov 08 2018 at 15:50, on Zulip):

then it does not complain

nagisa (Nov 08 2018 at 15:50, on Zulip):

oh

pnkfelix (Nov 08 2018 at 15:50, on Zulip):

even if errors were emitted, as long as they match the .stderr file

pnkfelix (Nov 08 2018 at 15:51, on Zulip):

I believe the intention was that, if you have a particular class of diagnostic in your //~ annotation, then all such diagnostics of that class would be checked.

mw (Nov 08 2018 at 15:51, on Zulip):

so the .stderr file is checked regardless? in don't see the problem then...

pnkfelix (Nov 08 2018 at 15:51, on Zulip):

the reason there's a problem is that people often --bless stderr files

pnkfelix (Nov 08 2018 at 15:51, on Zulip):

without care

nagisa (Nov 08 2018 at 15:51, on Zulip):

@mw the problem with .stderr is that nobody really authors those files by hand :slight_smile:

pnkfelix (Nov 08 2018 at 15:51, on Zulip):

the inline annotations force people to be honest about their expectations

mw (Nov 08 2018 at 15:52, on Zulip):

hm, ok

pnkfelix (Nov 08 2018 at 15:52, on Zulip):

Now, I personally would probably be fine with the status quo. But I'd also be fine if we required all the //~ ERROR s to be explicit

pnkfelix (Nov 08 2018 at 15:53, on Zulip):

(I'd be curious if anyone here would object tothat.)

mw (Nov 08 2018 at 15:53, on Zulip):

seems like a possible footgun that could easily be removed

pnkfelix (Nov 08 2018 at 15:53, on Zulip):

What I'm more on the fence about is requiring the //~ WARN annotations

varkor (Nov 08 2018 at 15:53, on Zulip):

I think warnings should be explicit as well

varkor (Nov 08 2018 at 15:54, on Zulip):

they can always be ignored if they're irrelevant to the test

pnkfelix (Nov 08 2018 at 15:54, on Zulip):

I suppose that the tests can always add #[allow(....)] for any warnings that they do not want to annotate, right? (As in, that is the exact point @varkor is making, right?)

davidtwco (Nov 08 2018 at 15:55, on Zulip):

I don't mind having //~ ERROR and //~ WARN be explicit - the test cases get really messy and bogged down when you need to annotate all of the labels and notes. Having the annotations assert that there was an error on line X and then the stderr assert that the error has the desired labels/suggestions/etc makes sense to me.

pnkfelix (Nov 08 2018 at 15:55, on Zulip):

okay. To be honest I hadn't really digested how easy it should be to work around the //~ WARN requirement via #![allow(..)] before talking about it here.

pnkfelix (Nov 08 2018 at 15:56, on Zulip):

So maybe we should just go whole hog with what @Vadim Petrochenkov is suggesting then? Any objections to seeing about moving forward with that?

pnkfelix (Nov 08 2018 at 15:56, on Zulip):

Obviously we'll have to fix the related compiletest bugs before this policy shift matters.

nikomatsakis (Nov 08 2018 at 15:56, on Zulip):

just catching up, but I'm in favor, I keep being surprised that we're not checking //~ ERROR

pnkfelix (Nov 08 2018 at 15:56, on Zulip):

okay

pnkfelix (Nov 08 2018 at 15:57, on Zulip):

that's all the I-nominated things

pnkfelix (Nov 08 2018 at 15:57, on Zulip):

holy cow there's a slew of stable-to-stable regressions ...

pnkfelix (Nov 08 2018 at 15:57, on Zulip):

how many of these are T-compiler...

pnkfelix (Nov 08 2018 at 15:58, on Zulip):

28

nikomatsakis (Nov 08 2018 at 15:58, on Zulip):

(are you filtering out already prioritized ones?)

pnkfelix (Nov 08 2018 at 15:58, on Zulip):

no i didn't

nikomatsakis (Nov 08 2018 at 15:58, on Zulip):

(arguably we should just close them since we're not going to fix them, but we haven't always done that)

pnkfelix (Nov 08 2018 at 15:58, on Zulip):

okay

pnkfelix (Nov 08 2018 at 15:58, on Zulip):

after filtering -label:P-{high,medium,low}, we're back to 0

pnkfelix (Nov 08 2018 at 15:59, on Zulip):

but then removing the T-compiler requirement brings us to 13 issues

pnkfelix (Nov 08 2018 at 15:59, on Zulip):

lucky 13

pnkfelix (Nov 08 2018 at 15:59, on Zulip):

most are probably libs

pnkfelix (Nov 08 2018 at 15:59, on Zulip):

but it would be good to triage the ones with no T-team label

pnkfelix (Nov 08 2018 at 16:00, on Zulip):

okay we're almost to the hour

pnkfelix (Nov 08 2018 at 16:00, on Zulip):

I'm feeling more sensitive to the fact that the meeting always runs over, since that came up at the steering meeting

pnkfelix (Nov 08 2018 at 16:00, on Zulip):

so I think we'll just call this over now.

pnkfelix (Nov 08 2018 at 16:02, on Zulip):

(thanks for joining, everyone!!)

nagisa (Nov 08 2018 at 16:03, on Zulip):

o/

Last update: Nov 16 2019 at 01:35UTC