On Wed, Apr 1, 2026 at 3:59 PM Gary Guo <[email protected]> wrote: > > I'm not sure that I parse this. You do remove the filter-out completely below?
(I see you saw the other commit) > Looks like this is going to conflict with rust-fixes (which adds the > --remap-path-scope). Perhaps worth doing a back merge? It would be only a couple lines conflicting, so it should be fine. Having said that, when I was doing this, I wondered if we should even consider keeping the workaround. In other words, locally for `rust-next`, the "normal" commit would be to remove the workaround entirely because there the flag doesn't exist to begin with (i.e. the workaround should have been removed back when the revert landed). Then, when conflict happens in linux-next, we can just keep the addition of the flag from your commit -- the rest can say as-is, i.e. no workaround needed, because you only enable both flags in a version (1.95.0) where there is no need for the workaround (which was for < 1.87.0). It is also why I added the second commit here, i.e. the "make it conditional", because I was testing that indeed we didn't need the workaround anymore. So it may just simpler to do that. What I thought was that perhaps the workaround is good even if we ourselves don't pass the flag, e.g. someone else may be passing it. But the chances are very low, restricted to a couple versions, and the error is obvious and at build time anyway. Cheers, Miguel
