DiagnosticEngine and the emission of diagnostics and notes on Windows

Greetings fellow developers from the land of Microsoft,

With lots of changes making their way into the tree, I'm starting to look at some of the quality of implementation issues with the toolchain. One thing that is now starting to come up is the diagnostics in swift. This is actually something pretty common in the test suite as well.

The problem stems in the fact that the diagnostic engine in swift is slightly different from clang. It uses a SuS (Single Unix Specification) extension in the printf which allows you to render arguments using numbered references. Unfortunately, Microsoft's printf implementation does not support this functionality.

I am really stuck on how to best address this. Do we really want to provide an implementation of printf in the compiler for this functionality? Do we want to use portable C standard only functionality? Or is there some other approach that might be nicer to take?

CC: @jrose @Chris_Lattner3 @Douglas_Gregor

It looks like we're only using it in one place right now, the AKAFormatString parameter for configuring DiagnosticFormatOptions. I know why that's there: some custom handling inside the Swift Playgrounds iOS app. I think it's okay to just have the compiler default value use positional format arguments only, maybe adding a comment saying the string must be compatible with the host platform's printf implementation.

Hmm, IIRC, the failures were all related to the type desugaring, so it is probably is just that string. Not sure I understand what you are suggesting then - just have a different specifier for the other targets?

The current value of the string is "'%1$s' (aka '%2$s')", which is equivalent to "'%s' (aka '%s')". Nothing in open source Swift overrides that string (that I could find); it's a customization point only used by out-of-tree clients. We should probably put in a gtest-style unit test to make sure it doesn't break, but other than that it's fine to simplify it on all targets.