Change:
<ins> // build-pass // compile-flags: --edition 2018 // compile-flags: --crate-type rlib use std::future::Future; async fn handle<F>(slf: &F) where F: Fn(&()) -> Box<dyn for<'a> Future<Output = ()> + Unpin>, { (slf)(&()).await; } fn main() {} </ins>

Discussion:
We are getting a duplicate symbol build error when compiling with . The error itself is (Full build with a RUSTBACKTRACE) The demangled symbol is That type referenced is from the predicatescore public crate, but unfortunately we have not yet narrowed down a reproduction beyond doing the full build. Believe this to be related to (specifically comment) cc:
Although there's nothing that looks like a cause, the actual code change that triggered the build failure was

It looks PR introduced a bug. Is it possible to revert this change until resolved? cc: , Note, line 154 starts a function declared within a proc macro: cc:
Can you link to the code that replicates this bug? It seems better to fix the bug rather than revert straight away, especially since was a pretty big refactor.
The referenced line/function is here: ;l=154 The proc macro definition is here: ;l=241
Urgh. So, a MCVE would be super helpful here. And this error is popping up in a bit of code I'm not at all familiar with. But just by guessing for the few minutes I've looked at this, we might need to erase late bound regions . As to exactly what's happening, I don't know. Because is printed out opaquely, I'm not sure if we're actually missing an upvar or if it's just a region difference (I imagine the latter). But not exactly sure where the region difference could have come from. I would definitely prefer not to revert , but if we need to, I'll live.
label +T-compiler
if I were to get build artifacts with my potential fix from above, would you be able to check whether or not it works?
One thing that might be helpful is to run with
I'm not building this locally. The error is from our CI system that dryruns rustc updates. So there's a bit of a setup, for me to build against a version of rust we haven't transitioned to. I will try to get it set up though. If you push a draft PR with your proposed patch, I can cherry-pick that on top of a pull with the breaking change and try to validate your fix. Running with is going to be nearly equal effort for me to set up.
I'm ready for your patch Jack so send it my way as soon as you can and I will try it.
here's a patch:
got it. I just tested locally with the latest rust without your patch and confirmed I can reproduce the error locally. I'm rebuilding with your patch now. Thanks!
Unfortunately that didn't work. But I can try adding now that I'm set up to build locally.

Here's what I'm getting as-is, with the patch:
With , I'm not sure I see much more:
I need to try that again (the )
OK, this has :
Okay weird. is which makes sense, because we erased all bound vars But witness has which looks the same except for the late bound regions, which I would have thought would have been replaced by in
only erases one level of binders, i think, could that be related?
I mean, the bound vars in the witness are definitely bound correctly: (bound by the on types, not on the binders) does descend through s, so it should be seeing that bound var. So, really not sure. Maybe the isn't returning true on the ?
suggested sharing the output of :
can I get you to try another patch for me? I'm not expecting this to change anything, but running with should help debug some more. I appreciate it!
It's important to note: the output that we saw above with from the decl that was erased is actually coming directly from ( not ) i.e. regions were already erased (good) and makes sense why erasing regions again didn't change anything. But I'm wondering if that bit is causing problems.
not found in umm...hashing issue?
I believe I have also run into this issue compiling Tide as a dependency of tide-sqlx. See this github run: <details<summarylog copied for posterity</summary</detailsI'm not quite sure if I can get from the github actions machine, but it did print out this:
Some extra info - that was from running , which we use to do .
Reduced from the regression:
You can remove the by adding an Unpin bound: Strangely, changing to makes the ICE go away: but an arbitrary still has the panic:
So, uh, that's great. But I just popped it in a unit test and it didn't it clearly does on the playground...investigating
I did the same and discovered it only repros when building rlib rather than bin. This test is failing: Am also investigating... :-)
- How close are you to a fix? I'm concerned that this is still blocking my project's ability to roll forward, so unless you have a plan to fix this very soon, I'd like to ask about reverting your change until there is a solution.

I'm still willing to help you verify the fix, but I thought I should ask since it's been a while since your last trial patch. Thanks
Well, we have a , so shouldn't need you to test patches (but thank you, it did help me start looking). I'm at work today, so I won't have time until this evening to dig into this more. is also potentially looking into this a bit (I think?). Now that we have a minimal repro, narrowing down the problem should be fairly quick, so I'm confident I can get a fix tonight or tomorrow. If not, I personally think this is serious enough that we should revert temporarily (blocks Fushia and tide; easy enough to hit). But I'm not sure that needs to happen before the weekend is over.
I agree. We can wait until early next week, and a fix is preferable to everyone I think. Thanks for the estimate.
is there a reason you're using the very latest nightly for such a large project? Part of the point of nightly is to give us time to fix bugs before they hit stable.
Fuchsia is not a tier 1 target, so we run our own CI and build Fuchsia against every bors merge. We don't use nightly, but instead try to update to the latest tip-of-tree once a week. We do the same for clang. A project of this size can exercise a lot of edge cases in the compiler, and we regularly find bugs in rustc and LLVM. The cost of fixing bugs is usually much lower right after they're introduced, so getting bug reports like this one up sooner than later is a big help (to everyone, hopefully). Without this we have ended up in a situation where we're blocked from updating the compiler for many weeks. The other reason we do this is because we're doing active feature development in the compiler (source-based code coverage) and are testing it out in our own infrastructure. So breakage can create a situation where we're blocked from testing out those changes. Breaking our rustc CI is not a huge deal, and we can always tolerate not updating the compiler one week. But the longer our CI is red and the further behind our production compiler gets, the more bugs can "sneak in" that will have to be unwound later. So we prefer to get it green as soon as we can.

I think this is helpful to the project overall. But of course it has to be balanced against other concerns, like the overall impact and (as in this case) the difficulty of reverting and re-landing a big change. To be clear, I don't want us to be putting undue pressure on the project to revert a change because it inconveniences us. But if a fix isn't already in sight, it's worth asking the question. A clearer policy around when to revert might be helpful here; I think the release team has floated the idea of writing one before.
Update: problem identified, just have to figure out best fix
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-high
- We found a second compiler failure that only crops up when enabling : It breaks when compiling a third-party crate--arbitrary--for at least some versions of that crate. We are currently locking in version , but the repo only tags back to . Fortunately, I can easily reproduce the error on both versions, so the instructions for anyone to repro this are fairly straightforward: The mangled name demangles to: Is this error resolved by your proposed fix as well?
- So, I cherry-picked your proposed and unfortunately it still fails (for the problem I reported initially). However it does fix the error I just reported above, with . I'll add a note to your PR, and provided the updated verbose output.
Cross posting from We found the . A closure was being coerced to a function pointer in an async fn. The unused came out of that coercion somehow. Removing the type attribution on that binding fixed the ICE for us.