```
@_specialize(exported: true, spi: SPIGroupName, where T == Int)
public func myFunc() { }
```
The specialized entry point is only visible for modules that import
using `_spi(SPIGroupName) import ModuleDefiningMyFunc `.
rdar://64993425
Rename ImportedModuleDesc to AttributedImport and make it a template that’s parameterized on the representation of the module. This will allow us to reduce duplicated representations of “abstract” ImportDecls.
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
The lack of clarity manifested as unexpected behavior when using
getImportedModules to create the module import graph. The new behavior
makes SPI-ness and Shadowing-ness behave similarly in terms of
filtering. We also check if a filter is well-formed to avoid
accidental empty import lists.
Remove the fast path skipping evaluating SPI groups for non-public
decls. This knowledge is still required to allow the use of SPI types in
the signatures of `@usableFromInline` declarations and in internal
properties of structs in non library evolution compilation.
rdar://68530659
rdar://68527580
Extensions to implementation-only types are accepted at type-checking
only if they don't define any public members. However if they declared a
conformance to a public type they were also printed in the
swiftinterface, making it unparsable because of an unknown type.
Still accept such extensions but don't print them.
rdar://problem/67516588
LLVM, as of 77e0e9e17daf0865620abcd41f692ab0642367c4, now builds with
-Wsuggest-override. Let's clean up the swift sources rather than disable
the warning locally.
* Re-create `ASTScope` for each completion
* Add generic params and where clause scope even without missing body
* Use `getOriginalBodySourceRange()` for `AbstractFunctionBodyScope`
* Source range translations for replaced ranges when finding scopes
* Bypass source range checks when the completion happens in the replaced
range
* Be lenient with ASTScope / DeclContext mismatch in code completion
…and modify resolveFileIDConflicts() to diagnose any such violations instead of asserting.
Swift does not allow any two files in the same module to have the same filename, even if they are in different directories. However, this is enforced in the driver, so tests that invoke the frontend directly can violate it. Turns out that a couple of those snuck into the test suite at various points.
This commit updates those tests. It also causes the frontend to diagnose the duplicate filename error just as the driver would have, which should help us understand what happened more easily if this crops up again in the future.
NFC, since invoking the frontend directly is unsupported.
Lift the `DisablePoundIfEvaluation` parsing option
into `LangOptions` to subsume the need for the
`EvaluateConditionals` parameter, and sink the
computation of `CanDelayBodies` down into
`createSourceFileForMainModule`.
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
Sink the `BuildSyntaxTree` and
`CollectParsedTokens` bits into
`SourceFile::ParsingFlags`, with a static method
to get the parsing options from the lang opts.
Also add a parsing flag for enabling the interface
hash, which can be used instead of calling
`enableInterfaceHash`.
Now that SIL files no longer interleave parsing
with type-checking, the query doesn't make much
sense. Inline it into its only client,
`shouldBuildSyntaxTree`.
Rather than replacing the code completion file
on the `CompilerInstance` whenever we do a cached
top-level completion, let's set a new main module
instead.
This allows us to properly update the
`LoadedModules` map, and allows the retrieval of
the code completion file to be turned into a
request.
Remove the `PrimarySourceFiles` vector from the
frontend and replace it with a request on
ModuleDecl that retrieves the primary files for
the main module.
This is in preparation for having
`CompilerInstance::getMainModule` automatically
populate the main module with files when queried.
Rather than adding a ModuleFile to a parent module
and then removing it afterwards if it fails to
load, let's wait until we've loaded the file before
deciding to add it to the parent module. This then
allows us to get rid of `ModuleDecl::removeFile`.
In addition, push down the calls to `addFile` into
the callers of `loadAST` in preparation for
`addFile` being replaced with a one-time-only call
to a `setFiles` method.
Using a SetVector fixes an issue where many source files imported the
same SPI group from the same module, the emitted private textual
interfaces superfluously repeated the `@_spi` attribute on the import.
rdar://problem/63681845
Re-implement operator and precedencegroup decl
lookup to use `namelookup::getAllImports` and
existing decl shadowing logic. This allows us to
find operator decls through `@_exported` imports,
prefer operator decls defined in the same module
over imported decls, and fixes a couple of other
subtle issues.
Because this new implementation is technically
source breaking, as we can find multiple results
where we used to only find one result, it's placed
behind the new Frontend flag
`-enable-new-operator-lookup` (with the aim of
enabling it by default when we get a new language
mode).
However the new logic will always be used if the
result is unambiguous. This means that e.g
`@_exported` operators will be instantly available
as long as there's only one candidate. If multiple
candidates are found, we fall back to the old
logic.
Resolves SR-12132.
Resolves rdar://59198796.
getOpaqueResultTypeDecl() can wind up invoking lazy function body
parsing when it runs availability checking. If any of those function
bodies have opaque result types, they will be inserted. If that
insertion happens to resize the SetVector, iterators will be invalidated
and a non-deterministic crash results.
Instead, use SetVector::takeVector() for the iteration so we have
a temporary copy whose iterators cannot be invalidated in this
situation. This also elegantly handles clearing out the vector for us.
Resolves rdar://62976771
