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.
Avoid parsing the syntax tree up-front, and instead
only parse it when required, which happens when either:
1. ASTGen parsing is enabled (currently disabled
by default)
2. Round trip checking is enabled for a primary
file (enabled by default in a debug build,
except when dep scanning or doing an IDE
operation)
3. We need to evaluate a macro in that file
This change therefore means that we now no longer
need to parse the syntax tree for secondary files
by default unless we specifically need to evaluate
a macro in them (e.g if we need to lookup a member
on a decl with an attached macro). And the same
for primaries in release builds.
rdar://109283847
Expression macros ascribed to non-private contexts need private
discriminators so they don't conflict with other uses of the same macro
in other source files.
Thank you, Richard, for noticing this omission!
The macro name resolution in the source lookup cache was only looking at
macros in the current module, meaning that any names introduced by peer
or declaration macros declared in one module but used in another would
not be found by name lookup.
Switch the source lookup cache over to using the same
`forEachPotentialResolvedMacro` API that is used by lookup within
types, so we have consistent name-lookup-level macro resolution in both
places.
... except that would be horribly cyclic, of course, so introduce name
lookup flags to ignore top-level declarations introduced by macro
expansions. This is semantically correct because macro expansions are
not allowed to introduce new macros anyway, because that would have
been a terrible idea.
Fixes rdar://107321469. Peer and declaration macros at module scope
should work a whole lot better now.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
On both input moduel source-files and interface files.
This currently yields dramatic scanning performance improvements at no cost - we do not require an AST during scan.
Using an access-level on imports limit how imported types can be used in
API. This change extends TypeAccessScopeChecker to return both the
access scope of the target type and any import that limits where it can
be used. Diagnostics should use this information to raise errors and
point to related imports.
Establish the relationship for generated sources, whether for macro
expansions or (via a small stretch) replacing function bodies with
other bodies, in the source manager itself. This makes the information
available for diagnostic rendering, and unifies a little bit of the
representation, although it isn't used for much yet.
`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
In the Swift grammar, the top-level of a source file is a mix of three
different kinds of "items": declarations, statements, and expressions.
However, the existing parser forces all of these into declarations at
parse time, wrapping statements and expressions in TopLevelCodeDecls,
so the primary API for getting the top-level entities in source files
is based on getting declarations.
Start generalizing the representation by storing ASTNode instances at
the top level, rather than declaration pointers, updating many (but
not all!) uses of this API. The walk over declarations is a (cached)
filter to pick out all of the declarations. Existing parsed files are
unaffected (the parser still creates top-level code declarations), but
the new "macro expansion" source file kind skips creating top-level
code declarations so we get the pure parse tree. Additionally, some
generalized clients (like ASTScope lookup) will now look at the list
of items, so they'll be able to walk into statements and expressions
without the intervening TopLevelCodeDecl.
Over time, I'd like to phase out `getTopLevelDecls()` entirely,
relying on the new `getTopLevelItems()` for parsed content. We can
introduce TopLevelCodeDecls more lazily for semantic walks.
Introduce a new source file kind to describe source files for macro
expansions, and include the macro expression that they expand. This
establishes a "parent" relationship
Also track every kind of auxiliary source file---whether for macro
expansions or other reasons---that is introduced into a module, adding
an operation that allows us to find the source file that contains a
given source location.
Rework the ASTGen interface to split apart parsing a source file,
turning the top-level declarations from that source file into C++ AST
nodes, and then deallocating that source file. Hold on to the source
file in the C++ SourceFile abstraction so we can query it later if we
need to.
And we will need to.
The effect of declaring an import `@_weakLinked` is to treat every declaration from the module as if it were declared with `@_weakLinked`. This is useful in environments where entire modules may not be present at runtime. Although it is already possible to instruct the linker to weakly link an entire dylib, a Swift attribute provides a way to declare intent in source code and also opens the door to diagnostics and other compiler behaviors that depend on knowing that all the module's symbols will be weakly linked.
rdar://96098097
Implicitly imported decls may end up in inlinable code and break the
module API. This have been known to lead to deserialization crash and
could in theory break the generated swiftinterfaces files. Let's
explicitly check for such a case, keeping it to a warning until Swift 6
where we can make it an error.
rdar://95816286
This prepares us to generalize ObjC selector collision diagnostics to also include protocols. NFC in this commit because, even though Sema and ClangImporter now try to record ObjC methods on non-`ClassDecl`s, `NominalTypeDecl::createObjCMethodLookup()` still doesn’t create ObjC method tables for them, so the calls are no-ops.
To help maintain source-compatibility, the presence of an `await` in
top-level code to kick the top-level code over to being a concurrent
context.
This, of course, means that in the test cases that exist today, they
will go back to behaving identically to how they did before I added all
of this because they don't have any awaits in the top-level. I'll be
adding new tests to verify the differences in behavior between swift 5,
swift 6, with and without async top level enabled in the next commit.
Introduce the `@preconcurrency` attribute name for `@_predatesConcurrency`,
which has been the favored name in the pitch thread so far. Retain the
old name for now to help smooth migration.
Rather than tacking the "add `@_predatesConcurrecy` to import"
diagnostic on to the prior diagnostic as a note, make it its own
remark. Then, ensure that we only emit this remark once per source
file per imported module, so we're not overwhelming the user.
Fix an issue where `if #available(...)` conditions were ignored in
emit-module-separately builds or when skipping non-inlinable function
bodies.
To handle functions for which parsing is delayed but type-checking is
not delayed, move up building the delayed TRC to the
TypeCheckFunctionBodyRequest service.
rdar://83166742
• There is now one access note success remark and fix-it per declaration, not per attribute/modifier.
• Failure remarks have been rephrased to better emphasize the cause of the failure.
• The wording of other access note remarks and notes have been changed to follow a similar formula.
