Hi Jian, On Thu, Apr 08, 2021 at 10:57:54AM -0700, Jian Cai wrote: > So this issue is blocking the LLVM upgrading on ChromeOS. Nathan, do > you mind sending out the smaller patch like Nick suggested just to see > what feedback we could get? I could send it for you if you are busy, > and please let me know what tags I should use in that case. > > Thanks, > Jian I will go ahead and send the smaller patch at some point today. For what it's worth, Nick brought up https://reviews.llvm.org/D100037, which may be relevant here. Cheers, Nathan > On Wed, Mar 31, 2021 at 3:06 PM Nick Desaulniers > <ndesaulniers@xxxxxxxxxx> wrote: > > > > On Wed, Mar 31, 2021 at 2:58 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > > > > > On Wed, Mar 31, 2021 at 02:27:03PM -0700, Jian Cai wrote: > > > > > > > > I just realized you already proposed solutions for skipping the check > > > > in https://lore.kernel.org/linux-block/20210310225240.4epj2mdmzt4vurr3@archlinux-ax161/#t. > > > > Do you have any plans to send them for review? > > > > > > I was hoping to gather some feedback on which option would be preferred > > > by Jens and the other ClangBuiltLinux folks before I sent them along. I > > > can send the first just to see what kind of feedback I can gather. > > > > Either approach is fine by me. The smaller might be easier to get > > accepted into stable. The larger approach will probably become more > > useful in the future (having the diag infra work properly with clang). > > I think the ball is kind of in Jens' court to decide. Would doing > > both be appropriate, Jens? Have the smaller patch tagged for stable > > disabling it for the whole file, then another commit on top not tagged > > for stable that adds the diag infra, and a third on top replacing the > > file level warning disablement with local diags to isolate this down > > to one case? It's a fair but small amount of churn IMO; but if Jens > > is not opposed it seems fine? > > -- > > Thanks, > > ~Nick Desaulniers