2 minutes and then some till the meeting @T-compiler.
Today is thanksgiving, so at least @nikomatsakis is known to be absent (also @pnkfelix is on a vacation).
Please react somehow so I know who’s participating. If there’s nobody else but me, I might just do some triage myself and call it a day.
Without a further ado…
P-high T-compiler 2 issues.
NLL error on closure, but not on equivalent function #55526 no progress, seems like @nikomatsakis hadn’t an opportunity to look at this, leaving assigned to @nikomatsakis, hopefully next week either him or @pnkfelix looks at this.
regression: stack overflow on macosx with xcode 6.4 #55471 no change here either. We ran a crater and found no genuine regressions. Still some perf issues and portability still needs to be worked out. I hadn’t an opportunity to get back to my portability work, maybe @Oli has anything more to say?
I'll revert the base-stack sizes and exclude windows for now
stacker has a PR to fix windows, but it needs a rebase and I don't understand what it does
Okay. Is the stacker PR linked on the rustc PR?
not yet, will cross-link
Either way this issue won’t be "fully" fixed until we get all platforms working to some extent.
Rust 2018 Release milestone 2 issues. 1 issue is T-lang, though relevant to us, I think?
Issue 56128 segment id ice nightly #56143. beta-accepted. @Vadim Petrochenkov has reviewed it and left some comments.
spoiler alert: this PR fixes a few issues we’ll talk about later on
Seems to be WIP still?
but @nikomatsakis is on it :)
yeah, it seems to still need some work on it
Seems in good hands either way. Does anybody know whether long weekend is a thing in the US?
Best case this will land on Friday.
"nikomatsakis added some commits 3 hours ago " :P
Next is [beta] resolve: Implement edition hygiene for imports and absolute paths #56053 Crater recently failed with quite a few regressions, which seem to have been anticipated. Seems to be in good hands and covered so no action necessary unless somebody wants to discuss it somehow?
This is otherwise a T-lang PR, so most of the decisions made here are for T-lang to make.
But some of you might want to review the code etc.
which is why I wanted to bring this to y'all’s attention.
Which is… Forward rust version number to tools #56134 Feels like T-infra/T-tools to me :slight_smile: @Oli you should also label a team along with the beta-nominated flag.
I did some more checking... None of the regressed crates on crates.io seem to have any reverse dependencies (except for one crate which has a reverse dependency due to the same author; the transitive & reflexive closure consists of 1 single reverse dep). The crates also don't seem to have many users. The ecosystem impact of this doesn't seem to be very notable.
I'll take a look at the code, but I'd lean on Centril's assessment there.
ups, yea, will add teams to nominations from now on
Am I correct that this is T-tools?
yes, I tagged it as such now
@Esteban Küber do you want to discuss that PR any further?
Personally to me 64 broken crates seems scary, regardless of what those crates are
@nagisa no, just pointing my agreement with the stated positions in the PR without spamming it :)
Okay. Moving on then,
stable-nominated 0 issues! :high_speed_train:
stable-to-beta-regressions 1 yet unreviewed issue.
Does P-high seem appropriate to everyone?
The other beta regression is the stack overflow one which also is being worked on (stacker).
stable-to-nightly-regressions 2 issues.
Miscompilation since rustc 1.32.0-nightly (04fdb44f5 2018-11-03) #56069 no minimal test case. Anybody wants to look at this? Smells like they might have UB unsafe code to me.
Might also be worthwhile to wait for the reporter to come up with a smaller reproducer as well
Wrote a comment on the issue indirectly requesting for the reproducer
Any objections to P-high?
/me decides to drive some conersation by interpreting +1 as an objection (not)
S-waiting-on-team T-compiler 0 issues!
I-nominated T-compiler 3 issues (2 of them nominated for WG-compiler-nll, not us)
Compiler in 1.30.1 stable reliably panics on Windows #56095 P-high, T1 platform. Could be related to windows machines having a tendency to accumulate uptime because it doesn’t do "real" restarts.
I recall mildly Windows having a debug option to start counting uptime from a very high value
react with a :thumbs_down: if you don't dislike not misinterpreting :+1:s as objections.
(also react with :+1: if you don’t disagree with P-high :slight_smile:)
this is really a libs issue
but we should maybe work around it nonetheless
Kind of, yes.
makes me wonder though, why this is coming up only now
Did something change in our compiler implementation? Perhaps there was some recent windows update that broke times?
While we're relabelling, lets also add an
because -Z self-profile hit stable?
i.e. the code seems to always be executed, not only if -Zself-profile is enabled
well, it seems there are two courses of action then:
1. Investigate what change in the compiler caused this to get triggered now, and perhaps workaround it;
there's a suggested fix here: https://github.com/rust-lang/rust/issues/51648
2. (T-libs) Figure out what causes a monotonically increasing timer to not increase in such a way.
I think we should:
1. ask @Wesley Wiser to implement the work-around
2. open a T-libs issue about
fn elapsed() panicking unexpectedly
Is there a ticket for the latter?
I haven't looked actually
I’m not aware of one, but can’t say I’ve looked for it either
https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+elapsed+panic nothing other than
rustc tickets here
Ah, and for the record, it seems to me that this issue is indeed a duplicate of the linked issue
(by @Wesley Wiser)
regardless of what the reporter says about it being more intermittent.
How often it happens is probably just an interaction with newer code in rustc
Okay, there seems to be some more activity going on, but lets just move on
Add a forever unstable opt-out of const qualification checks #56123 That’s a PR. @eddyb care to elaborate what the question here is?
The conversation in the PR is mostly about the colour of the shed
i.e. what the flag/feature name should be named like.
the question is whether we want a feature that is unsound to use by definition
it is great for testing and demonstrating unsoundness
well as long as it is a forever unstable debug feature, why not
it is always wrong to be used in user-space
that doesn’t sound like a good reason to add a debug flag though
I could see myself agreeing to it if it was instead marketed as
well... for RFCs around const stuff it's very hard to explain things
we had weirder debug flags either way
I'm not gonna market a feature in a way that I'm not planning on using it just to get it merged
@Oli are the demonstrations for the purpose of writing RFCs?
mostly giving examples why alternative X won't work
Would "internal unstable" (like the scope inside
println) be appropriate for this?
no, the libstd should never use this feature
I can in fact add assertions that guarantee it's not used in the libstd
making this feature a flag would make it impossible to misuse within libstd
or most of the code, really
that is a good argument for making it a flag
I'll bring this up in the PR
#[feature(nll)] made a lot of sense for experiments
but it also was indended to be used by crates
Just saying, that we definitely had (and have) all sorts of weird -Z flags most of which are never used except in very specific situations by few people
Okay, lets move on.
Internal Compiler Error in 1.30 and 1.31 #55846 seems to have been fixed in beta, a fix needs to be identified and perhaps backported. Also tested. Unless somebody volunteers, nothing to discuss here.
/me looks around the room for volunteers
Well it’s fixed anyway, :party_ball:!
There also some more issues, but they all seem to be reviewed already.
Finding the PR that fixed it would be nice to verify that a test was added.
Otherwise we'll need to come up with a repro.
We kinda have one, don’t we
(I mean we verified it as fixed using the (quite large, admittedly) piece of code that’s linked to on the issue)
Right, it just needs minifying :)
Well that’s not critical at all :slight_smile:
/me marks as E-help-wanted will write up what needs to be done
we could slap
E-mentor on it
thanks, Zulip, notifications only on my phone, which I wasn't looking at...
that concludes the agenda, mostly (I skipped looking at RFCs etc, which we don’t usually look at)
@varkor I usually slap
E-easy until I have time to come back and write mentoring instructions and add
E-mentor only then :)
anybody wants to raise a topic for discussion?
@Esteban Küber: in this case, the mentoring instructions should be: "reduce this test case as much as possible", so should be easy to write up :P
It's a very much WIP fix to an incorrectly allowed macro definition
The fallout is large
I'll put in the work to turn it into a proper lint, which will be warn by default
But this will still have a large fallout throughout many macro defining crates
rustc was guilty of exploiting this a lot!
Well, it is quite easy to
how does it behave currently?
does it greedily consume expressions separated by a space?
IIRC, it does
Seems like a sensible behaviour given the code
It seems sensible to lint this essentially forever
It seems to work in a greedy manner
while sure macro invocation appears to be super ambiguous.
I guess the issue here is compatibility hazard
Yep, I feel that this will have to be a perma-warn lint
oh, and where lints are impossible, it is fine to just warn
especially in cases like these :slight_smile:
does not make sense to give people ability to disable warning about buggy code that should be fixed
We're gonna get a lot of complaints...
deny(warnings) while at that.
It is a bug.
If we just warn (I'd be down with that), it'd make sense to keep it nightly only for two releases
even though it is a bug fix, widely used crates exploit it
including the generated serde code
keeping it nightly only for two releases should give the community time to move away from using this, and then we can enable it for all channels from then on
what do y'all think?
"it" here being the warning
Correct, a lint wouldn't need this much glove-handling
as each project could just adjust it and carry on as they were at their leisure
Well, thanks all for participating.
Sorry for derailing the ending there ^_^
Its fine, we had time :slight_smile:
doesn’t happen too often
Thanks for driving the meeting, @nagisa ! :heart: