[LLVMify F18] Replace uses of standard streams library with LLVM streams

[DavidTruby]

LLVM has its own stream library for a number of reasons, we should use this as well to sync up with them. See https://llvm.org/docs/CodingStandards.html for the reasons why their stream library is preferred.

[sscalpone]

Please look at semantics/mod-file.cpp to be sure it'll work. That the modfile is written to memory before writing to a file so f18 can avoid re-writing mod files that do not change. I don't anticipate a problem.

[DavidTruby]

Assuming I understand correctly that you mean the places where it outputs to a std::stringstream before writing that to a file, llvm has a raw_string_ostream class that is pretty much a drop in replacement for std::stringstream, so I can't see there being an issue.

[klausler]

Why replace the use of the standard library stringstream for the construction of the module file content? Is the nonstandard facility significantly faster?

[DavidTruby]

The non-standard facility is faster because it makes more assumptions about what the type of the buffer is. Additionally it's not templated so it can be forward declared safely. The code guidelines for llvm go over why they prefer the use of their streams library over standard streams. The standard streams library is also littered with global objects with non-trivial constructors that are pretty unsavoury.

[klausler]

How much faster does f18 run on a large compilation when using the nonstandard stringstream?

[DavidTruby]

I haven't had the time to port it yet. However I think it's a somewhat academic discussion as LLVM forbids the use of the standard streams library for a number of reasons, as listed in the LLVM code guidelines.

[klausler]

LLVM has historically avoided iostream objects because iostream requires run-time construction of static objects, which is a general prohibition for libraries. But sstream is specifically characterized as "not problematic".

[DavidTruby]

Sure, stringstream is not problematic in the same way. However, most llvm libraries only provide conversions to raw_ostream& etc, and raw_ostream is preferred over standard streams regardless for other reasons.

[RichBarton-Arm]

Progressing under #1047