just a quick heads up to @T-compiler members: we'll be having our weekly meeting here in about 45 minutes.
I might be away for part of it but I should be able to catch most of it
ho ho, I almost missed the start myself!
hi everyone (namely @T-compiler !)
so today might be interesting; from my earlier skim over the agenda items, it looks like we might be able to get through the boilerplate stuff relatively quickly today!
Hey there @Vadim Petrochenkov , great to have you here!
especially since you might be able to clarify my understanding of the state of #55094 "Weird filesystem hierarchy with nested modules"
looks like we're backing out that feature (according to https://github.com/rust-lang/rust/pull/55192#issuecomment-432059195)
so that's fine; but the dialogue on PR #55192 made it seem like we were backing it out due to the looming Wednesday deadline
Yep, unstabilized on 1.30 stable, needs crater to decide what to do next.
except my understanding is that we've delayed by a like a week? Is that incorrect?
Oh geeze this mess
@Vadim Petrochenkov you can probably start another run (sorry about the broken one!)
anyway, it sounds like #55094 is being dealt with, one way or another
and 1.30 is happening today (in a few hours), with that feature unstabilized
@Pietro Albini okay, so the 1.30 that's happening today is the stable release. Its the nightly->beta cut that has been delayed by a week, then?
(I see now, I misunderstood how far down the pipeline the regression described in #55094 had leaked. okay.)
I don't think so, but don't take my word for it
Oh, the nightly->beta cut is not delayed?
let me go find what comment made me think this
I believe that @simulacrum said something about delaying till Monday over in #wg-nll
the blog post says RC2 will be released on monday
Beta/nightly promotion is what I think matters here and that'll happen early next week
(what @Vadim Petrochenkov said)
This is all fine, from what I can tell, Just good for everyone to be aware of.
So it looks like #55094 is under control. Lets move along to next agenda item then.
there are two. First is "[WIP] Partial implementation of uniform paths 2.0 to land before beta" #55297
and @Vadim Petrochenkov reported there that work there will continue
second is "Keep resolved defs in path prefixes and emit them in save-analysis" #54145
which looks like its in the process of being massaged into landing
looking good indeed
(merge conflicts, but I assume ... hmm, no
@nrc on zulip?)
well I assume nick will take care of it.
pretty sure, yes
they mentioned to me how badly they wanted this PR to land :P
next up: beta-nominations. Empty list!
next up: stable-nominations: Empty list!
we already discussed #55094
#54709 is in FCP with disposition-close
I guess we could early-close it, with the release a few hours away
#54627 was discussed last week, with workarounds documented and us stating that we do not plan to have a fix in time for release.
I guess #54627 will be recategorized as stable-to-stable regression after the release, and it will join its compatriots there.
and the last of the stable-to-beta regressions: "[1.30 beta] Test suite of the jemalloc-ctl crate is failing" #54478 is actually fixed. Its just open because it needed a test, and there's a PR for that in the queue.
next agenda item: stable-to-nightly regressions
"NLL: cast causes failure to promote to static" #55288 is being worked on actively
"Unsized extern statics no longer compile" #55239 has a PR which is enqueued to be merged in a rollup
should we close the unspecific original issue then?
I don't have a problem with that.
and "Rustc panics on nightly with crate interpolate" #54654 ... I tried to reproduce this and could not. I'm waiting to see if we get more info from Boscop
having said that: This user is on windows-msvc
is there any reason why one might be more likely to see an ICE about "proc-macro crate not dylib" on that platform?
well anyway that's all the stable-to-nightly regressions
/me is so jazzed about getting this far into the agenda after only 25 minutes
Next agenda item: waiting for our team
only one issue here: "Support for the program data address space option of LLVM's Target Datalayout" #54993
there's sort of active discussion going on there
but it sounds like the main question is what to do with this given that there is also PR #51576: "Make
librustc_codegen_llvm aware of LLVM address spaces."
(seems like it's "in hand" though I do wonder if this is one of those cases that might merit an RFC or something.)
I'm thinking in particular of this comment from the author of PR #54993:
I see two ways forward:
Can someone answer that question for @Tim Neumann ? Who would be best to take point there?
One thing that I'm confused about is the intended purpose and scope of these changes
I guess I have to re-read the PRs, probably the information I want is in there
(in particular, does this affect the language in any way? etc — that all still feels a bit murky to me)
anyway, that doesn't answer your question, I don't really know the answer to that exactly
It seems to me like either @nikomatsakis or @eddyb is the best person to take charge on answering @Tim Neumann 's question
I can do that, I'll put a to-do item to bottom this out
okay, 29 minutes left and we've gotten to the I-nominated list
first: "path suggestions in Rust 2018 should point out the change in semantics" #55130
I think this actually has a PR in flight?
so I'm going to remove the nominated tag. I should have done that earler.
(yes, it does)
we just discussed #54993, so I'll skip that
next: "What should we guarantee regarding "sort-of unused" extern statics" #54388
boy I nominated this a while ago
oh right and we even discussed it
(for five minutes)
No one has added any more comments since then. I'm inclined to say that we've decided that the compiler's behavior here is "not buggy" and that the test should be revised to not try to exercise this.
assigning to self to do such revision of the test.
next: "run-pass/extern-pass-empty is probably a bogus thing to test" #53859
boy I nominated this a while ago
#53859 is what I was thinking of when I said this
We should not be pretending that
#[repr(C)] struct Empty works in our test suite, right?
My memory is that it issues a future-proofing warning
no i'm wrong, hmm
what the heck, I thought we had a lint about this when I filed this issue
funnily enough, we were just discussing this case in the UCG PR on structs and tuples
#[repr(C)] attached to an empty struct)
which is sort of a contradiction
since C has no such thing
#[repr(C)] on a zst doesn't make any sense to me but I'm probably missing something
no I dont think @Wesley Wiser is missing anything
it seems harmless though
should we just turn the issue into an issue about making this case warn?
support for them was added in "rustc: Fix x86 ffi for struct arguments" #12762
but I still cannot tell why
maybe because we didn't have
extern type at that time?
(I think the consensus of UCG team was that we ought to lint about
#[repr(C)] attached to a struct of zero-size, since it is misleading at best)
that is, weren't empty structs as some time used as a placeholder for
extern type? Or am I misremembering?
(see here for more discussion)
I will link to that discussion from the issue
we don't need to talk more about it here in that case
(also note that gcc and clang have extensions to permit zero-sized structs in C)
(tl;dr it's all weird and complex)
(also note that gcc and clang have extensions to permit zero-sized structs in C)
ah thats important to know
might be motivation to actually support it in that case
I'll read over the discussion of the UCG
next up: "Report const eval error inside the query" #53821
uh that just got FCP finished
I'll rebase and... r=reviewer I guess?
I'll kill the nominated tag there
next: "Rustc does not warn about
use with paths incompatible with
uniform_paths for edition 2018" #53797
we discussed this last week (at least accordinng to my own entry in the comments ...) lets see
looks like its being handled or at least triaged
I'm going to remove the nomination tag
next: "[Rust 2018] rustdoc doesn't link
"pub use whatever_crate;"" #52509
I'm trying to interpret imperio's comment
I take it that we do have ... a link to
rand ... but its being categorized as a module?
I guess if I really want to understand what's happening I should reproduce locally
anyway it sounds like imperio might be implicitly asking for assistance with how to make more progress.
or maybe even wants someone else to take over on it?
If I haven't finish this week-end, then please please ask someone else.
You know what, let me take this. imperio and I are in the same timezone and we know each other.
(dropping nomination tag from #52509)
getting to really old nominatinos now...
"Binaries compiled on Raspberry Pi with arm-unknown-linux-musleabihf fail on the same device" #51112
anyone have a R.Pi who'd like to look at this?
its (obviously?) low priority
in fact I'm going to remove the nominatino tag and mark it as P-medium
next: "Rust 1.26.0 fails to build on OS X 10.10.5" #50776
hmm. this might be homebrew specific?
I'll assign myself and try to take a look
but it seems P-medium to me
pretty old OS X version. Even I'm using something newer. :P
seems not high priority unless it's affecting many users
oh that's a good point
I didn't pay enough attentino to which OS X i twas
well we should verify whether it affects newer things I guess
actually, I'll mark as P-high for now
P-medium once I doulbe-check circumstances
i.e. if its homebrew specific
or old OS X specific
or a combinatino of the two
"Missed optimization: references from pointers aren't treated as noalias" #38941
so the main thing here seems to be this final comment from @eddyb :
Nominated for compiler team discussion - how should we track these instances of #16515?
I edited its description to reflect the current status, but can we do something more organized?
Do we want to close and open a new tracking issue?
(prompted by @shepmaster in https://github.com/rust-lang/rust/issues/38941#issuecomment-423776089)
in general, we do not have a good mechanism for tracking the performance of our generated code, full stop.
I'd love to see the perf server (or some other server) extended for this case; anp was working on that
(i'm adding the WG-codegen labels to these two issues as well)
I say we keep this particular issue open for now but make it clear that it falls under the general purvue of #16515 ...?
beyond that, maybe we want to make an actual Project for codegen and/or LLVM-usage improvements?
/me has been experimenting with the Project interface for NLL stuff
I'll make a comment saying as much.
Hmm. I'm skeptical, but maybe
I've found the project interface largely not to scale but maybe I've not been using it right
or have been using it for the wrong things
Oh I'm not saying I love it
I've been pretty unhappy with aspects. I.e. how much I have to use the mouse
but compared to editting the huge text body of an issue description ... it's an improvement. I think.
I can believe that :)
(the context here was the list of .nll.stderr differences)
A list of 460 files
/me chimes in to say that they will take over https://github.com/rust-lang/rust/pull/53514 and submit a replacement this weekend
I haven't figured out whether a project card-per-file is insanity or a net win
we should discuss DST for next meeting
but its what I'm trying right now, see: https://github.com/rust-lang/rust/projects/10
Daylight saving time or dynamic sized types :P
usually I have selfishly anchored the time to boston
Daylight savings time :) apparently we drift out of sync, I think, next week?
holy cow @nikomatsakis did mean Daylight Savings
yeah we drift, EU and USA are out of sync
not the first time those acronyms have been confused for one another
but only for a week or something? maybe two?
it makes the most sense just to keep a consistent UTC time
not to me :P
Yeah, we always anchored to Boston time, I think it is fine to keep doing that.
I'm flexible, I think. That is, I believe I can keep doing Boston time.
fine by me
as long as my calendar reflects the correct time, I can make either time
but I'm ok either way, I think, though it affects what the UCG team does =)
I think that is how the calendar invite is created
so if we do nothing else, it will stay that way
the other issue is that
my wife is pregnant with twins
oh you all may not know this
and the due date is coming up soon
I don't think I'm on that calendar, so maybe you could send me a link @nikomatsakis?
We can revisit this next year when EU disables DST altogether :P
so even though I might be fine with the timing
we still might need someone else to run the meeting
on short notice. :)
@pnkfelix I’ve ran a few meetings in the past, I could do this again if magical things start happening
okay thanks @nagisa
the biggest piece of advice I can offer: It is amazingly useful to do a prepass over the agenda before the meeting.
(that's probably something obvious to many of you. but its helped me a lot, I think, in terms of how smoothly these have gone recently.)
@varkor send me your e-mail and I'll add you — should find a way to make it a public thing
one other thing — tomorrow is compiler steering meeting, same time, same place
if you've not filled out the survey, please do so
So are we agreed to stay anchored to Boston time mostly, yeah?
later today I'll make some kind of summary of survey results, I guess? I didn't explicitly say that they would be made public, though I don't imagine it'd be too bad if they were (though I've not read all the responses :)
anyway more on that later
Okay. Great meeting everyone! Its good to get through all the agenda items, makes me feel good about the steering meeting tomorrow.
I’ll probably won’t be able to make meeting time tmrw, bringing my dog to a vet half an hour before, although the visit is expected to be short.
/me has to run to be get home, ttyal