Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
Various requests expect to be walking over the current source file.
While we could add checks to all these to skip decls outside of the
current buffer, it's a little nicer to handle this during the walk
instead.
Allow ignoring nodes that are from macro expansions and add that flag to
the various walks that expect it.
Also add a new `getOriginalAttrs` that filters out attributes in
generated source.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Semantically, the capture list binding behavior doesn't require the scope
to be an explicit closure, and forming new ClosureExprs during type-checking
is difficult because they have to have preassigned discriminators, unlike
AutoClosureExprs which get discriminators introduced by Sema itself. Allowing
CaptureListExpr to hold an AutoClosureExpr makes it easier to synthesize
CaptureListExprs during type checking, to represent expressions with closure
semantics that evaluate some parts of the expression eagerly in the surrounding
context.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
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
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
Add a new GenericContext::getParsedGenericParams(). This produces
the same value as GenericContext::getGenericParams() if the generic
parameter list was written in source. For extensions and protocols,
this returns nullptr without synthesizing anything.
doStuffWithList([
firstItem
.map { $0 } // This line should be indented further.
.append(\.foo), // And so should this one.
secondItem
])
Resolves rdar://problem/64834040
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
Annotate the covered switches with `llvm_unreachable` to avoid the MSVC
warning which does not recognise the covered switches. This allows us
to avoid a spew of warnings.
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
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.
They were missed before, so < > that should trigger outdenting weren't. E.g.
let x = foo<
Int, String, Int
>()
.count // Indented becase we didn't process the < > brackets previously.
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")
}
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
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
Since the return value of getAccessor() depends on mutable state, it
does not make sense in the request evaluator world. Let's begin by
removing some utility methods derived from getAccessor(), replacing
calls to them with calls to getAccessor().
