On Jun 28, 2022, Jonathan Wakely <jwak...@redhat.com> wrote: > I'll push this today.
Thanks! > You can just use --enable-libstdcxx-debug Thanks again ;-) > Again, that test is *supposed* to return without creating the > destination. It's testing the failure case. Aha, and that's why one shouldn't debug something without looking at the code to see what it's *supposed* to do ;-) >> FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc >> FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc >> >> .../27_io/filesystem/operations/copy.cc:5[67]: void test01(): >> Assertion '!exists(to)' failed. > I don't know what 5[67] means Sorry for being unclear, it's just that the corresponding failing asserts are at different lines in the two mentioned testcases, and I tried to convey that fact with regexp notation. > Which suggests to me another problem with mkstemp / nonexistent_path. *lightbulb powers up* Now it all makes sense. It isn't *another* problem, that probably regressed when the mkstemp patch went in and so it got out of my radar and thus out of the patchset I used in subsequent test runs, but because of the way I use the testing system, the baseline on top of which the patchset was installed was still was still that of the previous nightly build, so I effectively dropped the mkstemp fix. And since when I joined this project this bug had already been fixed, I didn't associate the regressions with the patch. Apologies for the noise. Today's baseline, plus your _At_path patch and my remove_all patch, is all clear. Yay! -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
