Start to use STL and stdio in superpmi

[huoyaoyuan]

As discussed in #112419, there should not be blocker for adopting C++ 17 in development environment. SuperPMI is I/O intensive and can be simplified significantly with std::filesystem.

It's non-starter to introduce C++ 17. Instead, using std::string can also simplify string manipulation a lot.

The end goal is to eliminate PAL simulation of Windows I/O functions. This PR acts as a first step to adopt STL in the dll shim entries.

[huoyaoyuan]

It seems that our linux glibc x64/x86/arm64 build environment aren't ready for C++ 17 STL. Is it because we are targeting the runtime version of lowest supported OS?

[janvorli]

We use Ubuntu 22.04 18.04 as cross build target for arm64. That one doesn't have support for c++17. So unless we decided to raise the minimum supported OSes in .NET, we are blocked.

[huoyaoyuan]

Is it OK to use some polyfill for superPMI only? We don't need strict compatibility or reliability here.

If this is too flaky, I can remove C++ 17 usage and convert to C++ 11 STL instad.

[jkotas]

I can remove C++ 17 usage and convert to C++ 11 STL instad.

What would you have to give up on by converting to C++ 11?

[huoyaoyuan]

What would you have to give up on by converting to C++ 11?

Everything in std::filesystem, currently just path that automatically converts to platform-native encoding. In superpmi it should be fine to use ANSI variants on Windows.

[AaronRobinsonMSFT]

What would you have to give up on by converting to C++ 11?

Everything in std::filesystem, currently just path that automatically converts to platform-native encoding. In superpmi it should be fine to use ANSI variants on Windows.

std::filesystem is a fine API, but we shouldn't really need it. It does help abstract away a lot, but it leveages C++ isms that people tend to balk at (for example, operator overloads). My preference would be to avoid std::filesystem in all cases and focus on collections and other language affordances that actually make the code simpler and explicit.

C++11 and C++14 are the biggest wins for the runtime repo from an API perspective.

[AaronRobinsonMSFT]

@huoyaoyuan In fact, I called this API out specifically in the referenced issue #112419 (comment). We shouldn't be using this without a real benefit. I don't see that in this PR.

[JulieLeeMSFT]

My preference would be to avoid std::filesystem in all cases

@huoyaoyuan, Given Aaron's comment to avoid std::filesystem, there isn't much point in pursuing this PR without it. What do you think?

[huoyaoyuan]

The major benefit of std::filesystem in superpmi is actually encoding handling of file names. Given its non-shipping tool, we can really avoid completed support.

I'll convert this PR to std::string and fstream based. They are still beneficial.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib PTAL. I'm signed off.

[JulieLeeMSFT]

@EgorBo, PTAL.

[JulieLeeMSFT]

LGTM.

[am11]

The end goal is to eliminate PAL simulation of Windows I/O functions. This PR acts as a first step to adopt STL in the dll shim entries.

src/native/libs handles the .NET libs' I/O needs in C99 pretty well. Most code under src/native/external is also ISO C. When there is a choice to avoid C++ runtime dependency, we tend to favor it.

[huoyaoyuan]

The build analysis failure looks like #121153.

[JulieLeeMSFT]

/ba-g timeouts related to #121153.

[JulieLeeMSFT]

/ba-g timeouts related to #121153.

[EgorBo]

/ba-g deadletter