vgvassilev wrote: > > > Here's a new reproducer, this time verifying that a semi-fresh > > > tip-of-the-tree doesn't trigger the same error: > > > https://pastebin.com/7tYfjazz. Apologies for the delay. > > > > > > Thanks. I gave it a try, but I don't see any `use of overloaded operator > > '=' is ambiguous` error. In fact, there isn't a `operator =` in the sources > > at all. What am I missing? 🤔 > > I didn't investigate the error - but could it come from autogenerated > operators? > > > Creduce-like tools are very bad at finding reject valid codes. > > @emaxx-google, can you paste your interestingness test? > > Here's the (slightly smaller) input: https://pastebin.com/dBy1T9fc . The > simplified script: https://pastebin.com/udVTaPYV . Its output: > https://pastebin.com/Mcq0Y0rf .
A reduce strategy that often worked for me is to have the broken compiler in modules mode but the working compiler in non-modules mode. If you prepend a tool such as https://github.com/Teemperor/hippie you can get all read by the compiler files in a readable area. Then you can use (-isysroot or the same tool to feed them back to the compiler). In this case you will have a "flat" TU which can run in both modules and non-modules mode. I hope that helps with that case, too... https://github.com/llvm/llvm-project/pull/133057 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
