I will be doing pre-triage in this channel.
Let's start with unprioritized, nominated issues
There...are a lot
STATUS_ACCESS_VIOLATION and STATUS_HEAP_CORRUPTION during compilation #63959
This seems to be related #63361 and the LLVM upgrade, again. It does not happen when target-cpu is not set.
(Is this a soundness hole?)
@Nikita Popov any thoughts on this?
I don't know what's the deal, @centril. I just posted this comment:
Checking in from @rust-lang/compiler triage:
cc @nikic and @nagisa -- Any thoughts on what's going on here?
I guess I'll tag it P-high and add to a list ("LLVM issues") to review
It sounds like @RalfJ could add a test for this to #63909?
I'd say this requires t-lang discussion
seems like it
let's nominate for t-lang
check_loanson stable #63932
this works on nightly and beta
and it is ICE => error
you could stable nominate it if you want to
yeah, seems like we can leave it
should we just close it as fixed?
if you don't think it should be stable nominated then let's close
(where stable nomination is judged on technical merits, not whether we will do a point release ultimately)
YEah. I'm fine either way but I think i'll just close to save everybody effort.
Blamed on an LLVM bug https://bugs.llvm.org/show_bug.cgi?id=43132
@Alex Crichton are you around by any chance?
I'm not sure what to do about this one but doesn't seem P-high
I'll mark as P-medium for now
My reasoning is that WASM is sort of a "WIP" target, but I'm not sure if that's the right way to think about things. =)
seems right-adjacent to me =P
Seems like the fix has something to do with rand versions
https://github.com/rust-lang/rust/pull/63806 is perhaps a fix?
bummer, no backtrace :frown:
this is nominated for t-lang, not us
there's been a lot of great work on minimization here
and a git bisect narrowed down to commit https://github.com/rust-lang/rust/commit/df0466d0bb807a7266cc8ac9931cd43b3e84b62e, which is an llvm upgrade
So many LLVM bugs :)
Feels like we need a specific alias to cc "LLVM folk"
Returning to the nominated issues...
selfimport when not in a list #63741
nominated for t-lang, I think
Also seems like T-lang, removing T-compiler for now
Hmm, this looks kinda luck a bug to me.
@Vadim Petrochenkov -- have you looked at #63687? Maybe it was listed also in one of the beta regressions?
hmm, doesn't seem p-high, but seems like a good documentation issue... let me think...
Hey @Sergey Togi Dashnyam -- iirc you were looking for a good first PR, this might be a simple one. It's a documentation question more than anything.
Optimization regression, caused by an LLVM backport which was itself fixing some other perf regression. Argh.
Seems unfortunate. I feel like we're going to call this P-medium. Would be nice if we had a way to "kick it" to the LLVM wg for consideration, but I know that there's no process for that (and nobody I think with enough dedicated time to keep such a pipeline going).
I guess I'll include it on my "focus list" for LLVM regressions.
document that target features are unsafe #63597
@nikomatsakis got it, will look into it.
dynis added/removed with
node_id_to_type: no type for node#51716
incremental bug, marking as p-medium, but it's a category we should address
nominated for both teams
@Igor Matuszewski this looks like a problem that is specific to save-analysis -- do you think you could take a look at it?
(should we kill save_analysis or what...)
@centril hopefully in some way or another yeah, but there’s still a use case for offline code knowledge dumping facility for offline code indexing (rather than IDEs)
It sounds like RalfJ could add a test for this to #63909?
looks like I could, yes. not sure if we want to.^^