Various uses of `getPresumedLineAndColumnForLoc` were likely added when
that function was the very misleading name `getLineAndColumn`. Change
these to use `getLineAndColumnForBuffer` instead where appropriate, ie.
we want the underlying file rather than the location to display to the
user.
There were also some cases where the buffer identifier had been swapped
to use the display name instead, under the assumption that the presumed
location was needed. Updated those as well.
SingleRawComment: Lines are only used when merging comments, where the
original location is fine to use.
Index: Doesn't store the file set in #sourceLocation, so using the
presumed line would end up pointing to a location that makes no sense.
Editor functionality: Formatting and refactoring are on the current
file. Using the presumed location would result in incorrect
replacements.
When the multi-line string is unterminated, the indentation of a line
will be the same as the first previous line that had contents, unless
that line is the line containing the start quotes. In that case the
indentation will be:
- the same as the start quote indentation, if the quotes are the only
contents on the line, or
- an extra indentation level to the start quote line otherwise
Lines within a terminated multi-line string or lines with content will
only ever be indented if their current indentation is invalid (ie. their
indentation level is less than that of their end quotes).
This rule is to prevent any signficant (and possibly unintended)
whitespace being added to existing strings during a whole file/range
format - Xcode does not remove whitespace from whitespace-only lines by
default. This could be improved if the reformat was sent the actual
range rather than a line at a time. Different indentation could then be
chosen if the range was in fact a single line.
Resolves rdar://32181422
Don't column align PBD entries if any entry spans from the same line as
the var/let to another line. E.g.
```
// Previous behavior:
let foo = someItem
.getValue(), // Column-alignment looks ok here, but...
bar = otherItem
.getValue()
getAThing()
.andDoStuffWithIt()
let foo = someItem
.getValue() // looks over-indented here, which is more common.
getOtherThing()
.andDoStuffWithIt()
// New behavior
getAThing()
.andDoStuffWithIt()
let foo = someItem
.getValue() // No column alignment in this case...
doOtherThing()
let foo = someItem
.getValue(), // Or in this case (unfortunate, but less common)...
bar = otherItem
.getValue()
let foo = someItem.getValue(),
bar = otherItem.getValue() // but still column-aligned in this case.
```
Resolves rdar://problem/63309288
E.g. if/guard condition patterns are column-aligned, but hitting enter after
the ',' below wasn't column-aligning the next empty line:
guard let x = Optional(42),
// No indentation added here after enter
Also the isTargetContext() check takes a start and end token location, but
wasn't accounting for the end location pointing a multiline string, so we
weren't walking into such nodes. This meant we didn't realise the target
location was within a multiline string in some cases, and we ended up
interfering with whitespace in its content.
Catch clauses now support mutliple patterns. Like 'case' patterns, these
should be column-aligned if split across multiple lines.
do {
...
} catch MyErr.a(let x),
MyErr.b(let x) {
print("hello")
}
We don't actually need to set a ContextOverride unless the ContextLoc and L
paren/brace/bracket are on different lines. Combined with the fact that we
only set them if the L and R parens/braces/brackets are on different lines
to, it guarantees there will be at most one override that's applicable on
any given line, which lets us simplify the logic somewhat.
- Rename several symbols to make it clearer whether the ranges they deal with
are open or closed.
- Add comments documenting the implementation of OutdentChecker::hasOutdent
- Fix a bug where code after a doc coment block of the '/**' style was being
indented 1 space.
- Fix IsInStringLiteral not being set if the indent target was in a string
segment of an interpolated multiline string.
- Update OutdentChecker::hasOutdent to propagate indent contexts from
parent parens/brackets/braces to child parens/brackets/braces that start
later in the same line (like FormatWalker already does). This changes the
braces in the example below to 'inherit' a ContextLoc from their parent
square brackets, which have a ContextLoc at 'foo'. This makes the whole
expression be correctly considered 'outdenting':
foo(a: "hello"
b: "hello")[x: {
print("hello")
}]
This restructures the indentation logic around producing a single IndentContext
for the line being indented. An IndentContext has:
- a ContextLoc, which points to a source location to indent relative to,
- a Kind, indicating whether we should align with that location exactly, or
with the start of the content on its containing line, and
- an IndentLevel with the relative number of levels to indent by.
It also improves the handling of:
- chained and nested parens, braces, square brackets and angle brackets, and
how those interact with the exact alignment of parameters, call arguments,
and tuple, array and dictionary elements.
- Indenting to the correct level after an incomplete expression, statement or
decl.
Resolves:
rdar://problem/59135010
rdar://problem/25519439
rdar://problem/50137394
rdar://problem/48410444
rdar://problem/48643521
rdar://problem/42171947
rdar://problem/40130724
rdar://problem/41405163
rdar://problem/39367027
rdar://problem/36332430
rdar://problem/34464828
rdar://problem/33113738
rdar://problem/32314354
rdar://problem/30106520
rdar://problem/29773848
rdar://problem/27301544
rdar://problem/27776466
rdar://problem/27230819
rdar://problem/25490868
rdar://problem/23482354
rdar://problem/20193017
rdar://problem/47117735
rdar://problem/55950781
rdar://problem/55939440
rdar://problem/53247352
rdar://problem/54326612
rdar://problem/53131527
rdar://problem/48399673
rdar://problem/51361639
rdar://problem/58285950
rdar://problem/58286076
rdar://problem/53828204
rdar://problem/58286182
rdar://problem/58504167
rdar://problem/58286327
rdar://problem/53828026
rdar://problem/57623821
rdar://problem/56965360
rdar://problem/54470937
rdar://problem/55580761
rdar://problem/46928002
rdar://problem/35807378
rdar://problem/39397252
rdar://problem/26692035
rdar://problem/33760223
rdar://problem/48934744
rdar://problem/43315903
rdar://problem/24630624
Previously closing square brackets would be caught in the logic for
elements in collections, indenting them to the same level. Now they are
indented with the normal non-sibling logic, which indents them
correctly.
[SourceKit] Indentation: when the indented line starts with open brace and the
line before starts with a leading declaration keywords, we never add
indentation level on the brace. rdar://28049927
* [Parser] Preserve empty getter functions to make sure indentation inside its body still works. rdar://28049927
* Using the consistent identifier even though they are identical.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
This ends up creating too much indentation in some common cases.
This effectively get us back to indentation behavior of Swift 2.2.
Addresses rdar://26290643.
