Stream: t-compiler

Topic: pre-meeting triage 2019-11-14 #54818


pnkfelix (Nov 14 2019 at 10:04, on Zulip):

I will be doing pre-triage in this channel.

pnkfelix (Nov 14 2019 at 10:10, on Zulip):

first up: unprioritized nominated T-compiler issues

pnkfelix (Nov 14 2019 at 10:10, on Zulip):

unpri nom 1/10: "clippy-driver no longer builds after rust-lang/rust#66233" #66409

pnkfelix (Nov 14 2019 at 10:10, on Zulip):

P-medium. removing nomination.

pnkfelix (Nov 14 2019 at 10:11, on Zulip):

unpri nom 2/10: "Compiler error while compiling Winrt" #66402

pnkfelix (Nov 14 2019 at 10:17, on Zulip):

classifying as P-high for now. Though the lack of a MCVE and the fact that the witnessing crate is presumably Windows-specific adds a bit of impedance to addressing this.

pnkfelix (Nov 14 2019 at 10:17, on Zulip):

unpri nom 3/10: "Compiler crash on "if" without "else" in async fn" #66387

pnkfelix (Nov 14 2019 at 10:18, on Zulip):

has PR

pnkfelix (Nov 14 2019 at 10:18, on Zulip):

classifying as P-high.

centril (Nov 14 2019 at 10:18, on Zulip):

(we have unnominated a few PRs which got PRs before the meeting)

centril (Nov 14 2019 at 10:18, on Zulip):

(we = release team)

pnkfelix (Nov 14 2019 at 10:19, on Zulip):

unpri nom 4/10: "Internal Compiler Error @ parser.rs:446:22" #66357

centril (Nov 14 2019 at 10:20, on Zulip):

I fixed yesterday :slight_smile:

pnkfelix (Nov 14 2019 at 10:20, on Zulip):

yeah I remember laughing when I saw fn f() { |[](* }

centril (Nov 14 2019 at 10:20, on Zulip):

:D

pnkfelix (Nov 14 2019 at 10:21, on Zulip):

classifying as P-high, unnominating.

pnkfelix (Nov 14 2019 at 10:21, on Zulip):

unpri nom 5/10: "ICE when using reference variable from iterator (instead of copying it): thread 'rustc' panicked at 'already borrowed: BorrowMutError'" #66353

centril (Nov 14 2019 at 10:22, on Zulip):

has PR, r+ed

pnkfelix (Nov 14 2019 at 10:24, on Zulip):

(just reading over the PR myself, and thinking about the borrow_mut failure)

centril (Nov 14 2019 at 10:27, on Zulip):

I r+ed it because we can do the principled fix some other time

pnkfelix (Nov 14 2019 at 10:27, on Zulip):

I'm musing about a debugging variant of RefCell that stored a stack-trace on each borrow, so that a borrow_mut failure could actually print a stack trace

centril (Nov 14 2019 at 10:27, on Zulip):

(assuming there is one)

pnkfelix (Nov 14 2019 at 10:27, on Zulip):

anyway I'm not going to do this now

pnkfelix (Nov 14 2019 at 10:28, on Zulip):

P-high. Removing nomination label.

pnkfelix (Nov 14 2019 at 10:29, on Zulip):

unpri nom 6/10: "Spurious x86_64 Windows CI failures due to OOM" #664342

pnkfelix (Nov 14 2019 at 10:30, on Zulip):

has PR. P-high. Removing nomination label.

pnkfelix (Nov 14 2019 at 10:30, on Zulip):

unpri nom 7/10: "miri no longer builds after rust-lang/rust#66252" #66301

pnkfelix (Nov 14 2019 at 10:31, on Zulip):

P-medium, removing nomination.

pnkfelix (Nov 14 2019 at 10:32, on Zulip):

unpri nom 8/10: "thread 'rustc' panicked at 'called Option::unwrap() on a None value'" #66286

pnkfelix (Nov 14 2019 at 10:32, on Zulip):

has PR. P-high. Removing nomination label.

pnkfelix (Nov 14 2019 at 10:33, on Zulip):

unpri nom 9/10: "improper_ctypes fires for &mut T, &T, *const T and *mut T" #66220

pnkfelix (Nov 14 2019 at 10:34, on Zulip):

so I nominated this, in part to decide if we should wait for nuance or post reverting PR. Since I nominated, a reversion PR was posted, r+'ed by eddyb, then r-'ed by rkruppe due to my own nomination (presumably they didn't want to step on our toes), and then re-r+'ed by me this morning.

pnkfelix (Nov 14 2019 at 10:35, on Zulip):

I'm going to triage it as P-high, but leave it nominated. I want to try to discuss at the meeting, at least for a little bit, what philosophy we want to follow when it comes to the Question of how eagerly to revert PR's in situations like this.

pnkfelix (Nov 14 2019 at 10:36, on Zulip):

(And also, i think the actual PR itself, in terms of the approach we want to strive for, is also worth discussing.)

pnkfelix (Nov 14 2019 at 10:38, on Zulip):

unpri nom 10/10: "sysroot spans are not printed on some targets (affected: Debian, rust-lang's own i586; unaffected: Fedora)" #53081

pnkfelix (Nov 14 2019 at 10:40, on Zulip):

marking P-high. Leaving nominated: the team should discuss solutions to this, maybe actually task someone with coming up with something.

pnkfelix (Nov 14 2019 at 10:42, on Zulip):

next up: beta-regressions without P-label

pnkfelix (Nov 14 2019 at 10:43, on Zulip):

beta-reg 1/2: "Large locals can cause OOMs during the ConstProp pass" #66397

pnkfelix (Nov 14 2019 at 10:43, on Zulip):

has PR. P-high.

pnkfelix (Nov 14 2019 at 10:44, on Zulip):

nominating the associated PR (#66394) for beta backport; but it only went up 10 hours ago so I don't expect us to actually backport it this week...

pnkfelix (Nov 14 2019 at 10:45, on Zulip):

unpri beta-reg 2/2: "SIGSEGV compiling num-integer for asmjs-unknown-emscripten" #66308

pnkfelix (Nov 14 2019 at 10:48, on Zulip):

what tier is this target?

centril (Nov 14 2019 at 10:48, on Zulip):

lemme check

centril (Nov 14 2019 at 10:48, on Zulip):

tier 2

pnkfelix (Nov 14 2019 at 10:48, on Zulip):

okay

pnkfelix (Nov 14 2019 at 10:49, on Zulip):

I'm going to triage this as P-high for now, at least for the initial investigation

pnkfelix (Nov 14 2019 at 10:50, on Zulip):

but given that its a tier 2 target ... well, I'll just say that I'm not committed to P-high for the long term.

pnkfelix (Nov 14 2019 at 10:51, on Zulip):

next up: nightly regressions without P-label ... there are none! :smiley:

pnkfelix (Nov 14 2019 at 10:53, on Zulip):

next up: reviewing all nominated issues to see if any should be unnominated (e.g. if they were discussed last week)

pnkfelix (Nov 14 2019 at 10:54, on Zulip):

we already discussed #66220 and #53081

pnkfelix (Nov 14 2019 at 10:55, on Zulip):

only other nomination is "Some features can no longer be controlled by conditional compilation" #65860 ... which I think we discussed last week ... lets see ...

centril (Nov 14 2019 at 10:55, on Zulip):

I need to get back to that

pnkfelix (Nov 14 2019 at 10:56, on Zulip):

ah right, we touched on it

centril (Nov 14 2019 at 10:56, on Zulip):

crater results are clearly favourable

centril (Nov 14 2019 at 10:56, on Zulip):

we then discussed it at t-lang

pnkfelix (Nov 14 2019 at 10:56, on Zulip):

I think the general feeling was that the triage meeting was not going to be the right place to discuss the question about the overall approach

pnkfelix (Nov 14 2019 at 10:57, on Zulip):

right; let me find the link to those notes from T-lang meeting

pnkfelix (Nov 14 2019 at 10:58, on Zulip):

I see this

centril (Nov 14 2019 at 10:58, on Zulip):

I definitely don't think that comment reflects the actual discussion in the lang meeting

pnkfelix (Nov 14 2019 at 10:59, on Zulip):

the lang meetings themselves are videotaped

centril (Nov 14 2019 at 10:59, on Zulip):

not the pre-triage :slight_smile:

pnkfelix (Nov 14 2019 at 10:59, on Zulip):

was this only discussed during T-lang pre-triage

pnkfelix (Nov 14 2019 at 10:59, on Zulip):

yeah okay that's what I figured

pnkfelix (Nov 14 2019 at 10:59, on Zulip):

(helps explain why I don't remember discussion)

centril (Nov 14 2019 at 11:00, on Zulip):

So I can maybe find the time to send some PRs (tho it's also not a requirement imo, and we've made things into hard errors with way more regressions than that, NLL errors in particular).
Beyond that, I think the PR should be re-reverted at least for the gates which had zero regressions. If someone wants to to propose something special about { and } then that is a language feature request and should go through an RFC

pnkfelix (Nov 14 2019 at 11:00, on Zulip):

I don't like the idea of using NLL as precedent here.

centril (Nov 14 2019 at 11:01, on Zulip):

@pnkfelix there are many other cases :slight_smile:

pnkfelix (Nov 14 2019 at 11:01, on Zulip):

anyway, the main thing to resolve right now is: Should this remain on the nominated items for T-compiler?

pnkfelix (Nov 14 2019 at 11:02, on Zulip):

or should it be shifted to T-lang? Or moved to async discussion?

centril (Nov 14 2019 at 11:02, on Zulip):

I'm not sure

pnkfelix (Nov 14 2019 at 11:02, on Zulip):

okay. I'll leave it nominated.

pnkfelix (Nov 14 2019 at 11:02, on Zulip):

(And will try harder to extract an answer to that Q at today's meeting.)

centril (Nov 14 2019 at 11:03, on Zulip):

I had meant to leave a comment but didn't find the time

pnkfelix (Nov 14 2019 at 11:04, on Zulip):

Alright. For the first time I think in three weeks, I've gotten to the P-high traversal with, I hope, plenty of time to actually do the traversal.

pnkfelix (Nov 14 2019 at 11:05, on Zulip):

lets traverse by LRU order today.

pnkfelix (Nov 14 2019 at 11:07, on Zulip):

P-high 1/36: "1.30 -> 1.31 dylib late-binding regression with GNU binutils 2.28 or older." #61539

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

I'll leave some comments

pnkfelix (Nov 14 2019 at 11:09, on Zulip):

(its essentially my bug. I'm debating about whether I should just downgrade to P-medium to reflect the reality of what severity we are treating this with ... )

pnkfelix (Nov 14 2019 at 11:11, on Zulip):

P-high 2/36: "Rustc does display a correct error message on type missmatch but does not show line numbers #51635

pnkfelix (Nov 14 2019 at 11:14, on Zulip):

still needs a more minimal MCVE (at least, I'd prefer one that replaces the use of rocket with a minimal proc-macro definition...)

pnkfelix (Nov 14 2019 at 11:22, on Zulip):

P-high 3/36: "Compiler crash on associated type violating its bounds in a blanket impl" #54108

pnkfelix (Nov 14 2019 at 11:23, on Zulip):

downgrading to P-medium (see discussion on ticket)

pnkfelix (Nov 14 2019 at 11:24, on Zulip):

P-high 4/36: "ICE when using anonymization in impl Trait with HRTB" #54895

pnkfelix (Nov 14 2019 at 11:28, on Zulip):

left comment on ticket and self-assigning.

pnkfelix (Nov 14 2019 at 11:29, on Zulip):

P-high 5/36: "ICE in macro: doc meta with expr on an item, string concat, stringify!(...)" #55414

pnkfelix (Nov 14 2019 at 11:36, on Zulip):

left a comment. This looks like it might be "easy" to resolve. Or maybe adding the desired visit method might cause regressions elsewhere: one might need to audit the existing Visitors to figure out whether the put back in the noop visit_token ; I imagine that audit is the hardest part of that fix, and probably the reason no one has taken this up yet.

pnkfelix (Nov 14 2019 at 11:37, on Zulip):

P-high 6/36: "ICE: Generic type alias to invalid type crashes during type check on latest stable" #62742

pnkfelix (Nov 14 2019 at 11:37, on Zulip):

(niko has been looking at this, and posted a comment back on October 9th. It seems like its getting the attention it deserves, in the literal sense...)

pnkfelix (Nov 14 2019 at 11:38, on Zulip):

P-high 7/36: "ICE resolving non-existent PartialEq::Eq from match of const" #65466

pnkfelix (Nov 14 2019 at 11:39, on Zulip):

I should at least check if my PR #66120 changes behavior here

pnkfelix (Nov 14 2019 at 11:39, on Zulip):

(a PR that I need to come back to...)

pnkfelix (Nov 14 2019 at 11:40, on Zulip):

P-high 8/36: "internal compiler error: src/librustc/dep_graph/graph.rs:688: DepNode Hir(...) should have been pre-allocated but wasn't." #62649

pnkfelix (Nov 14 2019 at 11:42, on Zulip):

(while looking at this, decided to close #66187 as duplicate)

pnkfelix (Nov 14 2019 at 11:47, on Zulip):

(while looking at this, decided to close #63150 as non-actionable without info about the delta that caused incr compilation to fail)

pnkfelix (Nov 14 2019 at 11:50, on Zulip):

left comment on #62649

pnkfelix (Nov 14 2019 at 11:51, on Zulip):

P-high 9/36 (or 34 now?): "ICE from const item in lifetime-parametric impl" #56445

pnkfelix (Nov 14 2019 at 11:52, on Zulip):

interesting comment there from github user PlasmaPower

pnkfelix (Nov 14 2019 at 11:58, on Zulip):

hmm. Tracking issue for const generics (#44580) has been locked

pnkfelix (Nov 14 2019 at 12:01, on Zulip):

(because there some vigorous discussion of syntactic alternatives on the thread, and people (rightly) pointed out that the tracking issue is not the right place for such discussion.)

pnkfelix (Nov 14 2019 at 12:03, on Zulip):

anyway I don't think there's anything to report here

pnkfelix (Nov 14 2019 at 12:03, on Zulip):

main question is whether it should remain P-high ...

pnkfelix (Nov 14 2019 at 12:04, on Zulip):

maybe we can prioritize figuring out a way to provide a better error message here?

pnkfelix (Nov 14 2019 at 12:11, on Zulip):

anyway left comment saying that.

pnkfelix (Nov 14 2019 at 12:12, on Zulip):

(and closed another issue I found as a duplicate of this one)

pnkfelix (Nov 14 2019 at 12:12, on Zulip):

P-high 10/34: "debuginfo/pretty-uninitialized-vec fails with Cannot access memory at address 0x7fffff7fe000" #64343

pnkfelix (Nov 14 2019 at 12:13, on Zulip):

hey @centril , did T-release end up just marking the debuginfo test here as // ignore ?

centril (Nov 14 2019 at 12:13, on Zulip):

havent had time yet

pnkfelix (Nov 14 2019 at 12:13, on Zulip):

okay just curious

centril (Nov 14 2019 at 12:13, on Zulip):

you can assign to me to do that

pnkfelix (Nov 14 2019 at 12:14, on Zulip):

okay I'll add you as assignee list

pnkfelix (Nov 14 2019 at 12:15, on Zulip):

(but if you do add the // ignore, I'm not sure the answer would be to close this bug. Probably better to just downgrade it to P-medium after the test is ignored ...?)

centril (Nov 14 2019 at 12:15, on Zulip):

yea

pnkfelix (Nov 14 2019 at 12:17, on Zulip):

P-high 11/34: "Rustc panics (NoSolution): could not prove Binder(projection soup)" #65581

pnkfelix (Nov 14 2019 at 12:18, on Zulip):

hmm. Should be investigated, but hasn't been since I marked it P-high 3 weeks ago.

pnkfelix (Nov 14 2019 at 12:19, on Zulip):

I'll post it in the main meeting area as a request for help

pnkfelix (Nov 14 2019 at 12:20, on Zulip):

P-high 12/34: "Coherence can be bypassed by an indirect impl for a trait object" #57893

pnkfelix (Nov 14 2019 at 12:21, on Zulip):

niko and others have been looking at this, as you can see from comments in issue

pnkfelix (Nov 14 2019 at 12:21, on Zulip):

has hypothetical fix put up for crater run in PR #66037

pnkfelix (Nov 14 2019 at 12:21, on Zulip):

so, things are actually progressing well there

pnkfelix (Nov 14 2019 at 12:22, on Zulip):

P-high 13/34: "ICE: errors resolving bounds after type-checking for fmt::Display" #65774

pnkfelix (Nov 14 2019 at 12:27, on Zulip):

some weeks ago I started a blog post on semi-mechanical techniques for turning code into an MCVE

pnkfelix (Nov 14 2019 at 12:27, on Zulip):

I really need to finish it

pnkfelix (Nov 14 2019 at 12:28, on Zulip):

(I think a significant number of people fail to provide an MCVE because they try to start small and build up -- but cannot find the path to the destination -- rather than starting from the original and cutting it down.)

pnkfelix (Nov 14 2019 at 12:42, on Zulip):

anyway, looked a bit at #65774. Couldn't reproduce (built accessifully, at least with certain flags that reflected those given in bug description.) Closing as non-reproducible (left more details in my comment on ticket).

pnkfelix (Nov 14 2019 at 12:42, on Zulip):

P-high 14/34: "Rust 1.38 regressions weren't fully triaged" #65577

pnkfelix (Nov 14 2019 at 12:42, on Zulip):

hmm no one has been assigned to do the actual triage here.

pnkfelix (Nov 14 2019 at 12:44, on Zulip):

left comment in main meeting area

centril (Nov 14 2019 at 12:44, on Zulip):

most of these are due to NLL stuff

pnkfelix (Nov 14 2019 at 12:44, on Zulip):

P-high 15/34: "LLVM ERROR: Access past stack top!" when compiling without sse2" #65844

pnkfelix (Nov 14 2019 at 12:45, on Zulip):

@centril the NLL stuff are the cases that @Matthew Jasper already triaged, right? The remaining work is five cases that are not related to NLL (or at least not obviously related)

centril (Nov 14 2019 at 12:45, on Zulip):

seems right yeah

pnkfelix (Nov 14 2019 at 12:46, on Zulip):

#65844 was advertised to LLVM ice breakers and we did get some info from comments on it

pnkfelix (Nov 14 2019 at 12:53, on Zulip):

and, oooh boy, I get a spurious segfault directly from my own rustc +nightly-2019-10-24 on it

pnkfelix (Nov 14 2019 at 12:54, on Zulip):

(assigned self for further investigation)

centril (Nov 14 2019 at 12:55, on Zulip):

@pnkfelix have I mentioned you self-assign too much? :D

pnkfelix (Nov 14 2019 at 12:55, on Zulip):

yep

pnkfelix (Nov 14 2019 at 12:55, on Zulip):

or rather

pnkfelix (Nov 14 2019 at 12:55, on Zulip):

I agree, and I'm trying to not do it so much

simulacrum (Nov 14 2019 at 12:55, on Zulip):

we should try it with an alt build

pnkfelix (Nov 14 2019 at 12:55, on Zulip):

what's an alt build?

pnkfelix (Nov 14 2019 at 12:56, on Zulip):

I agree, and I'm trying to not do it so much

(thus the :construction_worker: 's in the main meeting area)

pnkfelix (Nov 14 2019 at 12:57, on Zulip):

P-high 16/34: "ICE with impl Fn alias." #65918

pnkfelix (Nov 14 2019 at 12:57, on Zulip):

has a PR awaiting review in PR #65989

centril (Nov 14 2019 at 12:58, on Zulip):

@pnkfelix I think we can probably assign everything that is requires-nightly as P-medium max

centril (Nov 14 2019 at 12:58, on Zulip):

unless it's something we're actively trying to ready for stabilziation

pnkfelix (Nov 14 2019 at 12:58, on Zulip):

well, sometimes they are signs of deeper problems

pnkfelix (Nov 14 2019 at 12:58, on Zulip):

but I generally agree

centril (Nov 14 2019 at 12:58, on Zulip):

fair point

pnkfelix (Nov 14 2019 at 12:58, on Zulip):

it would be one way to try decrease the load of P-high issues, certainly

pnkfelix (Nov 14 2019 at 12:59, on Zulip):

P-high 17/34: "yet another associated type ICE (probably more missing normalize calls)" #65934

simulacrum (Nov 14 2019 at 12:59, on Zulip):

an alt build has llvm asserts and IR verification

pnkfelix (Nov 14 2019 at 13:00, on Zulip):

do alt builds have the full debug stuff from LLVM? E.g. do lines like LLVM_DEBUG(dbgs() << "Ignores Dead GUID: " << VI << "\n"); do useful stuff on such builds?

simulacrum (Nov 14 2019 at 13:01, on Zulip):

hm, not sure. Maybe not :)

pnkfelix (Nov 14 2019 at 13:02, on Zulip):

Just curious. (I just initiated a local build that hopefully has those bits enabled before starting the triage, as part of investigating a ThinLTO issue; but if I can get support for it from somewhere I can rustup or curl/wget, I would be thrilled...)

pnkfelix (Nov 14 2019 at 13:03, on Zulip):

regarding #65934, nothings happened. Not sure how to best handle the set of bugs that all seem to fall under lazy-normalization and/or insufficient-normalization ...

pnkfelix (Nov 14 2019 at 13:06, on Zulip):

but it did remind me to look at "Associated types, impl traits ~and closures~; oh my, an ICE." #63154 , which I have now closed as fixed.

pnkfelix (Nov 14 2019 at 13:07, on Zulip):

(which would have been 18/34)

pnkfelix (Nov 14 2019 at 13:09, on Zulip):

P-high 19/34 (or maybe 30, heh): "rust-lld since 1.38 overlaps .text with .rodata for embedded arm target" #65391

pnkfelix (Nov 14 2019 at 13:12, on Zulip):

left a comment

pnkfelix (Nov 14 2019 at 13:13, on Zulip):

P-high 20/30: "Miscompilation with target-cpu=znver1 (AMD Ryzen 1000/2000 series) on Windows + LLVM 9." #63959

pnkfelix (Nov 14 2019 at 13:15, on Zulip):

@eddyb's been looking pretty heavily into this, but they also said that they're unlikely to look into it much further, though they are willing to provide support for others who want to

pnkfelix (Nov 14 2019 at 13:15, on Zulip):

I'll post a :construction_worker: in the main meeting area

pnkfelix (Nov 14 2019 at 13:18, on Zulip):

P-high 21/30: "The compiler should report publicly exported type names if possible" #21934

pnkfelix (Nov 14 2019 at 13:18, on Zulip):

there's been much recent activity in the comment thread here, including ... <felix squints> ... a Pre-RFC

pnkfelix (Nov 14 2019 at 13:19, on Zulip):

I, like @Manish Goregaokar , don't think an RFC is necessary here. At most a design meeting, I suspect, and even that may be overkill.

pnkfelix (Nov 14 2019 at 13:19, on Zulip):

I'll post a comment to that effect.

pnkfelix (Nov 14 2019 at 13:22, on Zulip):

P-high 12/30: "async fn presence affects an unrelated error message" #66312

pnkfelix (Nov 14 2019 at 13:23, on Zulip):

scary scary scary!

pnkfelix (Nov 14 2019 at 13:23, on Zulip):

lets definitely keep our eyes on this one

pnkfelix (Nov 14 2019 at 13:23, on Zulip):

P-high 13/30: "Some features can no longer be controlled by conditional compilation" #65860

pnkfelix (Nov 14 2019 at 13:24, on Zulip):

we already touched on this up above. I'll make a note of it in the main mtg channel so people have time to prep if they're following there right now

pnkfelix (Nov 14 2019 at 13:26, on Zulip):

P-high 24/30: " Incremental compilation results in linker error when method use is removed" #59535

pnkfelix (Nov 14 2019 at 13:27, on Zulip):

all I can say is that I've been working my butt off trying to 1. reduce and 2. understand this bug. It arises due to a nasty confluence of features.

pnkfelix (Nov 14 2019 at 13:27, on Zulip):

but its as "in hand" as it can be...

pnkfelix (Nov 14 2019 at 13:27, on Zulip):

P-high 25/30: "ICE when using reference variable from iterator (instead of copying it): thread 'rustc' panicked at 'already borrowed: BorrowMutError'" #66353

pnkfelix (Nov 14 2019 at 13:29, on Zulip):

(we touched on this briefly up above. The ICE itself is being papered-over via a delay_span_bug in PR #66388. I am still musing about whether we should have a stack-trace-capturing DebugRefCell to provide more context when things like this arise ...)

pnkfelix (Nov 14 2019 at 13:29, on Zulip):

in any case, it seems like it is in hand for now

pnkfelix (Nov 14 2019 at 13:30, on Zulip):

P-high 26/30: "Spurious x86_64 Windows CI failures due to OOM" #66342

pnkfelix (Nov 14 2019 at 13:31, on Zulip):

(we covered this already when I went over the nominations; it has a PR)

pnkfelix (Nov 14 2019 at 13:32, on Zulip):

same for "thread 'rustc' panicked at 'called Option::unwrap() on a None value'" #66286

pnkfelix (Nov 14 2019 at 13:33, on Zulip):

yeah all the rest we've already covered, I think

pnkfelix (Nov 14 2019 at 13:34, on Zulip):

gonna go over the beta-nominations and make sure all relevant ones have T-compiler label too

pnkfelix (Nov 14 2019 at 13:35, on Zulip):

I forget to add it to PR #66394 before; fixed now

pnkfelix (Nov 14 2019 at 13:35, on Zulip):

added T-compiler to "Fix ICE when trying to suggest Type<> instead of Type() #66390 too

pnkfelix (Nov 14 2019 at 13:36, on Zulip):

added T-compiler to "find_deprecation: deprecation attr may be ill-formed meta." #66381

pnkfelix (Nov 14 2019 at 13:37, on Zulip):

added T-compiler to "parser: don't use unreachable!() in fn unexpected." #66361

pnkfelix (Nov 14 2019 at 13:37, on Zulip):

added T-compiler to "Undo an assert causing an ICE until we fix the underlying problem" #66250

pnkfelix (Nov 14 2019 at 13:38, on Zulip):

wow that means we have 7 beta-nominations to get through today

pnkfelix (Nov 14 2019 at 13:41, on Zulip):

but "only" five nominations, so I guess that balances out

pnkfelix (Nov 14 2019 at 13:46, on Zulip):

an alt build has llvm asserts and IR verification

@simulacrum are the alt builds made in parallel with the nightlies? In other words: Can I grab them via rustup ?

simulacrum (Nov 14 2019 at 13:46, on Zulip):

hm.. not sure about rustup

simulacrum (Nov 14 2019 at 13:46, on Zulip):

rustup-toolchain-install-master can do it

pnkfelix (Nov 14 2019 at 13:46, on Zulip):

(I skimmed rust-forge to see if the answer is there, but did not see anything about at builds there)

simulacrum (Nov 14 2019 at 13:46, on Zulip):

we produce them for every commit, though

pnkfelix (Nov 14 2019 at 13:46, on Zulip):

ah sweeeeeet

simulacrum (Nov 14 2019 at 13:46, on Zulip):

these days they're also parallel compilers

simulacrum (Nov 14 2019 at 13:47, on Zulip):

but the default is -Zthreads=1 so that shouldn't affect much other than performance

pnkfelix (Nov 14 2019 at 13:47, on Zulip):

(as in, you get the overhead drawback but no parallelization benefit by default, right?)

simulacrum (Nov 14 2019 at 13:47, on Zulip):

yep

centril (Nov 14 2019 at 13:59, on Zulip):

@pnkfelix oops my bad; forgot to label those

eddyb (Nov 14 2019 at 14:00, on Zulip):

I'm musing about a debugging variant of RefCell that stored a stack-trace on each borrow, so that a borrow_mut failure could actually print a stack trace

can't wait to land @anp's #[track_caller] implementation, then we can store at the very least a single &'static Location, which is just one pointer of overhead, might be fine to just enable it on all debug-assertions builds of rustc

(it's no backtrace but far more useful than RefCell methods panicking)

eddyb (Nov 14 2019 at 14:07, on Zulip):

hmm. Tracking issue for const generics (#44580) has been locked

oops I meant to go through and mark most comments as offtopic, maybe I should do that now :P

centril (Nov 14 2019 at 14:09, on Zulip):

it can stay locked I think

centril (Nov 14 2019 at 14:09, on Zulip):

people should file bugs via issues

eddyb (Nov 14 2019 at 14:15, on Zulip):

oh yeah I just wanted to make sure the offtopic discussion wasn't in everyone's faces - @varkor's update comment is what people should see :)

eddyb (Nov 14 2019 at 14:18, on Zulip):

(I think a significant number of people fail to provide an MCVE because they try to start small and build up -- but cannot find the path to the destination -- rather than starting from the original and cutting it down.)

@pnkfelix I'm not even sure what "MCVE" stands for. I always prefer to talk about "reducing" and "reduction" because it's clear that you chip away at something large (heh it's kinda like subtractive manufacturing i.e. machining away material)

and reduction techniques are fun, like getting rid of function bodies, replacing them with loop {} or even using black_box (in case weird optimization bugs are involved), so big :+1: on teaching more people about them

eddyb (Nov 14 2019 at 14:20, on Zulip):

but also there are rare cases when building something up does work, it just requires already having a mental model for why the problem happened - like building a stress test by using macros to generate a lot of the one thing you're pretty sure is inefficient (or specifically causes quadratic or worse behavior)

pnkfelix (Nov 14 2019 at 14:20, on Zulip):

Of course building up can work

pnkfelix (Nov 14 2019 at 14:20, on Zulip):

But my point was that I’ve seen people give up after it falls

eddyb (Nov 14 2019 at 14:20, on Zulip):

(but I'm preaching to the choir here unless other people see what I wrote lol)

pnkfelix (Nov 14 2019 at 14:21, on Zulip):

Well maybe I’ll finish up my desired blog post and then Let you suggest additions. :)

eddyb (Nov 14 2019 at 14:21, on Zulip):

@pnkfelix yeah I think I'd tell them not to bother with de-novo reproduction unless they've already done a reduction. and maybe we can rename E-needs-mcve? unless MCVE is an industry standard term and I'm just out of touch :P

eddyb (Nov 14 2019 at 14:22, on Zulip):

oh I expect the blog post is good already, just hyping myself for it

pnkfelix (Nov 14 2019 at 14:22, on Zulip):

I had to google it myself

eddyb (Nov 14 2019 at 14:22, on Zulip):

wait so who created the label?!

pnkfelix (Nov 14 2019 at 14:22, on Zulip):

(MCVE); but I *know * I’m out of touch

eddyb (Nov 14 2019 at 14:22, on Zulip):

(kinda crazy how things happen nowadays and I have no idea when or where they did, just see the aftermath)

pnkfelix (Nov 14 2019 at 14:23, on Zulip):

It is relatively google-able though

pnkfelix (Nov 14 2019 at 14:23, on Zulip):

Compared to say “minimize” or “reduction”

pnkfelix (Nov 14 2019 at 14:23, on Zulip):

In terms of getting the right thing in the top ... three hits

eddyb (Nov 14 2019 at 14:23, on Zulip):

LOL https://en.wikipedia.org/wiki/MCVE

eddyb (Nov 14 2019 at 14:24, on Zulip):

I love how wikipedia links to SO

eddyb (Nov 14 2019 at 14:25, on Zulip):

@pnkfelix uhhhh this puts the less effective approach first https://stackoverflow.com/help/minimal-reproducible-example

eddyb (Nov 14 2019 at 14:25, on Zulip):

maybe it works for things that aren't compiler bugs :P?

pnkfelix (Nov 14 2019 at 14:26, on Zulip):

To be fair, I didn’t say you shouldn’t build up at all, or that you shouldn’t try it first

pnkfelix (Nov 14 2019 at 14:26, on Zulip):

I think we all try it first

eddyb (Nov 14 2019 at 14:26, on Zulip):

but okay I won't argue with googleability metrics - I still think we should use "reduction" or "reduced" if we actually leave a comment (maybe we should have a bot that links your blog post :P)

pnkfelix (Nov 14 2019 at 14:27, on Zulip):

Let’s finish the post before the bot. ;)

eddyb (Nov 14 2019 at 14:27, on Zulip):

tick :clock: tock :clock: :)

pnkfelix (Nov 14 2019 at 14:27, on Zulip):

Just call me Adrian Veidt

eddyb (Nov 14 2019 at 14:33, on Zulip):

I think we all try it first

not in my most recent couple of reductions, but maybe that's just because all I had were large amounts of code and a somewhat opaque predicate for "does this cause the problem"

pnkfelix (Nov 14 2019 at 14:36, on Zulip):

have you seen my mind-bending reduction for #59535

pnkfelix (Nov 14 2019 at 14:37, on Zulip):

I can only imagine how those impl R {} blocks are influencing ThinLTO

eddyb (Nov 14 2019 at 14:37, on Zulip):

the hell

eddyb (Nov 14 2019 at 14:38, on Zulip):

@pnkfelix one explanation is you're injecting symbol name length variation

eddyb (Nov 14 2019 at 14:38, on Zulip):

have you tried varying some of the names involved?

pnkfelix (Nov 14 2019 at 14:38, on Zulip):

yeah alpha-renaming stuff also can cause the bug to go away

pnkfelix (Nov 14 2019 at 14:38, on Zulip):

so its certainly a factor

eddyb (Nov 14 2019 at 14:38, on Zulip):

okay have you tried uhhh removing several hundred impls and adding one character to a name?

eddyb (Nov 14 2019 at 14:39, on Zulip):

effectively treating the log10 of the number of impls as a parameter

eddyb (Nov 14 2019 at 14:39, on Zulip):

(I wish I never had to say those words)

pnkfelix (Nov 14 2019 at 14:39, on Zulip):

I suppose that would be one way to try to further reduce those tests

pnkfelix (Nov 14 2019 at 14:40, on Zulip):

but at this point I think I'm better off working within the execution of rustc+LLVM that I can observe

eddyb (Nov 14 2019 at 14:40, on Zulip):

the other thing is you might be fudging some partitioning algorithms, worse case being ofc a hash

pnkfelix (Nov 14 2019 at 14:40, on Zulip):

i.e. I now have a pretty strong theory as to what's going wrong

pnkfelix (Nov 14 2019 at 14:41, on Zulip):

(though I'm not yet sure which of LLVM or rustc get the blame for the problem)

eddyb (Nov 14 2019 at 14:41, on Zulip):

one thing you could do is script the number of impl R {}s to find other values for which it repros

pnkfelix (Nov 14 2019 at 14:41, on Zulip):

yeah I considering writing a macro to help with such a search

pnkfelix (Nov 14 2019 at 14:42, on Zulip):

i suppose when it comes time to post a regression test as part of a PR, I'll prefer to have a further reduced example in hand . . . so the time doing further reduction wouldn't have been wasted (assuming me or someone else eventually posts a fix)

centril (Nov 14 2019 at 14:45, on Zulip):

we should do shrinking on ASTs :D

eddyb (Nov 14 2019 at 14:47, on Zulip):

I think creduce technically supports Rust? I just don't really trust fully automated tools, I'd prefer something I can still guide

centril (Nov 14 2019 at 14:48, on Zulip):

is that a fuzzer? -- I was thinking using QuickCheck / proptest

eddyb (Nov 14 2019 at 14:49, on Zulip):

it's a reducer :P

centril (Nov 14 2019 at 14:49, on Zulip):

I don't know what a reducer is

eddyb (Nov 14 2019 at 14:49, on Zulip):

none of "fuzzers / quickcheck / proptest" do incremental reductions AFAIK

eddyb (Nov 14 2019 at 14:49, on Zulip):

@centril it reduces an input while keeping a property

centril (Nov 14 2019 at 14:50, on Zulip):

@eddyb that's exactly what shrinking (esp. the ddmin algorithm) is about

eddyb (Nov 14 2019 at 14:50, on Zulip):

you said shrinking which could make sense as being the same thing, but... oh

centril (Nov 14 2019 at 14:50, on Zulip):

and that's what QC does

eddyb (Nov 14 2019 at 14:50, on Zulip):

@centril okay, but creduce is a much more specialized tool

eddyb (Nov 14 2019 at 14:50, on Zulip):

for code input

centril (Nov 14 2019 at 14:50, on Zulip):

yea "shrinking" is standard terminology in testing

pnkfelix (Nov 14 2019 at 14:51, on Zulip):

/me is out of touch of what "quickcheck" describes

eddyb (Nov 14 2019 at 14:51, on Zulip):

it's not as simple as treating such a problem as an unit test though

centril (Nov 14 2019 at 14:51, on Zulip):

@pnkfelix https://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/quick.pdf

eddyb (Nov 14 2019 at 14:51, on Zulip):

all of those tools are designed to generate de-novo input

pnkfelix (Nov 14 2019 at 14:52, on Zulip):

none of the words "shrink", "reduce", nor "minimize" occur in that paper

eddyb (Nov 14 2019 at 14:52, on Zulip):

creduce is entirely about small changes to input code, and it understands enough to avoid making unreasonable changes

centril (Nov 14 2019 at 14:52, on Zulip):

Well quickcheck is a 2-step problem:

  1. generate test input
  2. shrink failing input to a minimum failing
pnkfelix (Nov 14 2019 at 14:52, on Zulip):

to be clear: I know what quickcheck was (in terms of generating test input).

pnkfelix (Nov 14 2019 at 14:52, on Zulip):

I just didn't know it handled shrinking as well

eddyb (Nov 14 2019 at 14:53, on Zulip):

but really what I want is a refactor toolkit that lets me do various steps faster than I can by hand

pnkfelix (Nov 14 2019 at 14:53, on Zulip):

I'm just happy that M-x kill-sexp usually works in Emacs

pnkfelix (Nov 14 2019 at 14:53, on Zulip):

for Rust blocks

centril (Nov 14 2019 at 14:53, on Zulip):

@pnkfelix argh; that paper is a bit dated... https://hackage.haskell.org/package/QuickCheck-2.13.2/docs/Test-QuickCheck.html#v:shrink

eddyb (Nov 14 2019 at 14:54, on Zulip):

something like creduce would only come in when I ran out of low-hanging fruit, but even then it tends to make a mess

pnkfelix (Nov 14 2019 at 14:54, on Zulip):

(M-x kill-sexp is my current go-to method for replacing a method body with { loop { } } when I need to do it repeatedly on a large body of code.)

eddyb (Nov 14 2019 at 14:54, on Zulip):

@centril yeah that looks too simple to do much for code

pnkfelix (Nov 14 2019 at 14:55, on Zulip):

(that or -Z everybody-loops, but for some reason I didn't use that in my most recent effort.)

centril (Nov 14 2019 at 14:55, on Zulip):

@eddyb it's simple but deceptively powerful

centril (Nov 14 2019 at 14:55, on Zulip):

smallcheck might make more sense for compiler inputs tho -- less random, more "search whole space up to Depth"

centril (Nov 14 2019 at 14:55, on Zulip):

but maybe that takes too much time

eddyb (Nov 14 2019 at 14:56, on Zulip):

"naive methods applied to ASTs produce reducers" is an extraordinary claim that I'd prefer seeing a proof of concept of before bothering to attempt

centril (Nov 14 2019 at 14:57, on Zulip):

it gets much harder with graphs

Last update: Dec 12 2019 at 01:45UTC