Use std compliant non-method std::filesystem::exists function

[jdlangs]

I was looking into updating rcpputils::fs to be more compliant with std::filesystem for an eventual C++17 migration and found the current functionality includes a path::exists() method which doesn't exist in std::filesystem. This simply changes usage to the non-member function and can be merged regardless of any future changes to rcpputils.

[fujitatomoya]

lgtm

[clalancette]

Seems reasonable. I'll run CI on it next.

[clalancette]

CI:

• Linux
• Linux-aarch64
• macOS
• Windows

[clalancette]

All right, CI looks good, so merging. Thanks for the contribution.

[jdlangs]

Thanks!

I'm not familiar with the procedure for getting stuff like this backported; what are the usual steps? Am I expected to take the lead on it?

[clalancette]

I'm not familiar with the procedure for getting stuff like this backported; what are the usual steps? Am I expected to take the lead on it?

That's most expedient, yes. Though I'm not entirely sure this makes sense to backport. First, it is only in a test. And second, we won't be switching Foxy to C++17, so the fact that it isn't 100% compliant with std::filesystem doesn't matter as much. What's your thinking here?

[jdlangs]

It's really just so I don't have to keep around a forked version if combined with a modified rcpputils (since I'll have foxy versions as my baseline). But yeah, it's not a huge improvement since the std::filesystem stuff can't be backported anyways.

Is the process just opening a PR against foxy with this commit cherry-picked on to a new branch?

[clalancette]

Is the process just opening a PR against foxy with this commit cherry-picked on to a new branch?

Yeah, that should do it for this PR.

[jdlangs]

Ok thanks; if it looks like it will save some effort I'll go ahead with that, otherwise I won't bother you guys.