Hi @WG-compiler-nll ; the weekly meeting will be held here in this (corrected) topic, starting in 2 minutes
my internet at my temporary location continues to be terrible
in any case, members of @WG-compiler-nll who have status updates to report should post them to the triage Paper; I see there are already some updates posted there.
i've been semi-following progress over the past week++; I got impression that our main focus (or at least the one that Niko wanted more attention paid to?) was correctness concerns
((of course continued improvements to diagnostics are welcome))
for some reason, my browser's rendering of the paper triage document is not including actual hyperlinks for the numbered issues
or wait, maybe some are just missing the actual hyperlinks...
I can't see any without hyperlinks at a glance.
yeh all have hyperlinks
well in any case my internet woes mean I won't be attempted to fine tune the content there
I'll leave that job up to you all
(the #53124 is missing the link for me)
(I think it is just your end)
but I'm suspecting its some local rendering issue
anyway maybe someone else can attempt to summarize our status with respect to correctness, here in channel?
I'm getting back to rustc work this week but also I'm in Portland for Rustconf :)
Just so I can feel like I'm aware of what's going on?
that's why I didn't fill the doc
(the biggest correctness issue I'm aware of is the issue to respect user-provided type annotations, something that Niko put up a PR for that corrects a lot of the problems there but not all of them...)
I've not been too on top of the NLL PRs this week, I think the only correctness stuff going on is the type annotations that Niko is doing.
also, in case anyone is not aware of it, I initiated the request to "stabilize" the NLL feature about 11 days ago: #43234
I was a little surprised by the protocol here
There's also the "fake access" for
match doing too much access.
@Matthew Jasper Oh that rings a bell; is that a NLL-sound issue, or an NLL-complete issue?
yes okay I think I remember seeing an issue that Niko and RalfJung filed about the fake match accesses...
hmm maybe I am misremembering and thinking of #53198
okay well in any case https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3ANLL-sound+ is looking pretty good to me
(assuming we can fix #47184 in a reasonable amount of time; I imagine I can tackle some of it either next week once I'm home (still on PTO but will have better internet and fewer distractions when Logan is asleep)...)
Is #51269 just needing a test or is there work to be done there?
and #53172 is looking pretty good too
Are the remaining crates there not done because of errors or because it just hasn't been done?
Yes, #51269 needs a decision on whether the code should be allowed or not.
I think ... #51269 does still need a decision
niko's comment there does not strike me as a decision
The remaining crates are external deps AFAIK
but rather as the beginning to a conversation
The remaining crates are external deps AFAIK
Makes sense. Is that issue done in that case?
so wait are we basicaly done with #53172?
So far that sounds like two votes for "closing as task complete"
Well, I'm not sure, I assume @Matthew Jasper is correct.
@memoryruins was the one working on this so he might know.
"external dep" may be a relative notion here...
liblibc is, AFAICT, a git submodule that is hosted in rust-lang/ github
and libbacktrace and libcompiler_builtins (and stdsimd) are in rust-lang-nursery/ github
So its not as obvious what the policy should be for them, as it would be for say crates that were on crates.io
having said that
I also see no need to change them
so lets just close the issue
I opened #53351 after doing the
Someone who's particularly good at working out whether something is working as intended might want to look at that.
i can do that
i both have a bit of time and usually am pretty decent at the detective work necessary here
by the way: @davidtwco I don't know if @nikomatsakis already told you this
but my usual way to deal with a test that fails in one mode but not another, when this is intended, is to tag an empty
fn main() on the test with
if you want me to provide more info on this, I can do so in a dedicated topic after the meeting
((there do remain cases where it still made the most sense to use
// ignore-test-compare-nll, but even then I think a lot of those cases are ones where the test is using revisions to explicitly encode the flags for AST-borrowck vs NLL vs something else when relevant...))
okay that's 30 minutes and I'm tired of babbling
are there any burning questions anyone wants to ask?
Yeah, I'm aware of that - @nikomatsakis has pointed it out and you have in a previous PR of mine too. I don't think most of them are using revisions. Not sure why I decided to go with the
ignore-test-compare-nll comment but I'll try get that right in future.
well its not a matter of "right" or "wrong"
more like "Felix's way puts more work onto the autotest system, so that must be the best option" ;)
but seriously: my thinking here is, if you use
// ignore-test-compare-nll, then (unless there is some other similar variant test that does cover nll), then that's a case where we don't have anything double-checking when the NLL behavior changes on that case
there are cases where that makes sense, but its not an avenue that I'd take lightly.
Having said that, I'm not sure how many people take that much care when they see changes to the .stderr output
there may be some people out there who are blindly passing
--bless and committing the results, for all I know...
(and if that's the case, then all the caution that I speak of is ... well, its not that important then...)
But I'm babbling again
okay well if there isn't anything else, then I'm going to see about diving into this list on #53351
That all makes sense.
hey all — sorry I missed the meeting — @pnkfelix regarding my thoughts on the focus, I do think we want to get all the sound/complete stuff buttoned down, but it seems to me that we're doing pretty good on that front (though we have to finish up the type annotation work). I need to get back to the type annot prob -- though I doubt I will do anything this week owing to RustConf -- but I confess I've mostly been worrying about perf lately.