On Tue, 28 Jun 2022 at 13:04, Alexandre Oliva <ol...@gnu.org> wrote: > > 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.
Doh! Of course. I thought it was some rtems thing. /facepalm > > > 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. Makes sense. > Apologies for the noise. Today's baseline, plus your _At_path patch and > my remove_all patch, is all clear. Yay! Great!
