Fix formatting issue with IfConfigDecl/ImportDecl interaction.

[shawnhyam]

The ImportDecl syntax node disables all line breaks (other than hard). This creates code that fails to compile when #if/#endif are involved (see example), removing all the line breaks after the #if <clause> as well as the #endif. Switching to hard line breaks would certainly work but feels a bit heavy handed and could end up with extra line breaks in other scenarios.

[shawnhyam]

@allevato I'm wondering if you have any thoughts on this; I want to make sure I'm understanding everything correctly and that there aren't any other logic bugs. We insert a printerControl token on an ImportDecl node that disables breaking, which seems to disable all breaking other than .hard (is this correct?). Since we can have an #if clause at the beginning of an ImportDecl statement, that would imply we need a .hard line break at the end of each condition, as well as the #endif. However, I believe a hard line break may give us too many newlines in other contexts where breaking is enabled. But the newlines are absolutely required, so maybe this is the best approach anyway? Or maybe the pretty print features aren't interacting the way they're intended to...

[allevato]

I think we want to keep the overall stylistic idea that "imports look better all on one line", and so we only need to fix that logic specifically for imports that have #if-surrounded attributes. (There's value to having one-line imports in the general case; other than just having them look better when they're a block at the top of the file, naïve regex-based tools can scan imports without having to do a full parse or require swift-syntax.)

So, I think we can address this a different way. What if, in TokenStreamCreator.visit(ImportDeclSyntax), we just check to see if the decl's attributes contain any IfConfigDecls? If it does, move the printer control token to precede the importKeyword token instead of the attribute list. Then, it will allow the attributes to span multiple lines (fixing the #if case) without causing unwanted wrapping for simpler imports.

Sure, that breaks the promise we're making to simpler tools that might want to quickly scan for those imports, but they were never going to handle something that complicated anyway without a full parse (and #if config evaluation).

[shawnhyam]

That sounds like a more promising approach than what I'd considered so far, so I'll give that a try. Thanks for your thoughts!

[allevato]

Can these changes be avoided? The idea is that the indentation of these would be the same if there weren't an intervening #if-config; i.e., we wouldn't have this:

SomeFunction(
  foo,
  bar
)
  .commonModifier()