The module-scope lookup tables use the same code for adding
module-scope declarations as for adding member operators, which are
found via "global" operator lookup. This requires us to expand macros
that can produce members of types, which violates the outside-in
expansion rule described in the proposals.
Stop recording member-producing macros, whether they are peer macros
applied to member declarations or are freestanding declaration macros
within a member context. This re-establishes the outside-in expansion
rule. It also means that member operators introduced by macro
expansion won't be found by global operator lookup, which is a
(necessary) semantic change.
Well, this is fun. Due to the use of the module-scope lookup table to
find operators, we need to carefully filter out any macro-introduced
declarations that *aren't* operators when forming the module-scope
lookup table. Otherwise, we can find macro-introduced static entities
within types... from completely unrelated scopes.
Fixes rdar://109219036.
API development sometimes requires a redesign while supporting early
adopters. Currently this is done by adding @_spi(name) to the API but
that requires adding the attribute in import statements as well, causing
manual overhead of adding and then removing when the redesign is done.
This PR introduces a special spi group name '_' and allows an implicit
spi import of a module containing API attributed with '@_spi(_)'
Resolves rdar://109797632
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
These metatypes are a gateway to more incorrect
uses of these noncopyable values because we don't
yet have the corresponding runtime support yet.
The other use cases of using metatypes of
noncopyable types in generics is not high enough to
warrant people using them yet.
resolves rdar://106452518
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!
It doesn't seem like there's any client that's
actually taking advantage of setting it to `false`,
and its default value of `false` is more likely
than not going to cause clients to accidentally
miss comments that they may want. In fact, this
was exactly the case for code completion's brief
field. Finally, the parameter wasn't even
consistently applied, as we would attempt to
deserialize swiftdoc comments even if it were
`false`.
This method was misleading. The majority of callers (all but one!) don't want
to unconditionally treat all locations in any macro expansion buffer the
same way, because the code also must handle nested macro expansions. There
is one part of SourceKit (and possibly others) that really do want to ignore
all macro expansions, but those can be handled within SourceKit / IDE code,
because I don't believe this utility is useful in the frontend.
Teach `getTopLevelDeclsWithAuxiliaryDecls` not to provide extension
declarations, because those are covered by the synthesized file, which
all clients need to walk anyway. Without this, we end up asserting in
TBD generation about duplicate symbol visitation.
Encountered while investigating rdar://108056018.
Whenever we perform a name lookup, we need to make sure to expand
all macros that use `names: arbitrary`, because of course they can
produce... wait for it... arbitrary names, and we don't know what they
are until we instatiate them.
When we look into expanded macros to find declarations for module-scope
name lookup, make sure that we only return declarations whose name
matches the requested name.
We were effectively spamming the results with unrelated names, and
most clients trust the results of this lookup (vs. filtering them
further), so they would get confused. The particular failure for this
test is that type reconstruction would fail because we were looking
for one unique name, but we found many non-matching names, and type
reconstruction bails out rather than try to filter further.
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
Pass back the original location (ie. where the macro was expanded, not
the location that the generated code would be inserted) for cursor info
and indexing. Also mark any declarations/references within generated
source as implicit.
Resolves rdar://107209132.
`updateNonUserModule` was accidentally copying `SearchPathOptions`. Take
a reference to it instead. Also, since `addFile` is actually called many
times (once for every submodule, of which there are many), change
`isNonUserModule` to a request so that it's only calculated when needed.
Resolves rdar://107155587.
Differentiate `internal` and `fileprivate` imports from
implementation-only imports at the module-wide level to offer a
different module loading strategy. The main difference is for non-public
imports from a module with testing enabled to be loaded by transitive
clients.
Ideally, we would only load transitive non-public dependencies on
testable imports of the middle module. The current module loading logic
doesn't allow for this behavior easily as a module may be first loaded
for a normal import and extra dependencies would have to be loaded on
later imports. We may want to refactor the module loading logic to allow
this if needed.
rdar://106514965
Rather than using `ModuleDecl::isSystemModule()` to determine whether a
module is not a user module, instead check whether the module was
defined adjacent to the compiler or if it's part of the SDK.
If no SDK path was given, then `isSystemModule` is still used as a
fallback.
Resolves rdar://89253201.
names in the source lookup cache.
Invoking macro expansion while populating the source lookup cache is deliberately
avoided because it's prone to circularity. This applies to member attribute expansion,
which is requested via `getSemanticAttrs()`. Populating the auxiliary decl cache
should use the original attribute list, because declarations found via global lookup,
such as macro and operator decls, cannot have inferred attached macros.
Previously, implicit imports were also being added to the module interface during override checking (without any diagnostic).
Additionally, correct the structure of the import which contained an extra, duplicated path component. It would be diagnosed as a scoped import and written into the interface like this:
```
import UIKit/*.UIKit*/
```
Resolves rdar://104935794
* Weakly reference ModuleDecl from PackageUnit
* Add PackageUnit decl context getter and use it for a package AccessScope
* Return module decl referenced by PackageUnit in getModuleScopeContext and getParentModule
* Handle package acl in access scope checkers
* Remove AccessLimitKind
* Fix tests
Resolves rdar://104987295, rdar://105187216, rdar://104723918
This modifies the ClangImporter to introduce an opaque placeholder
representation for forward declared Objective-C interfaces and
protocols when imported into Swift.
In the compiler, the new functionality is hidden behind a frontend
flag -enable-import-objc-forward-declarations, and is on by default
for language mode >6.
The feature is disabled entirely in LLDB expression evaluation / Swift
REPL, regardless of language version.
While a Swift program cannot directly utter one of the unique names
produced by the macro expansion context outside of the macro itself,
utilities such as type reconstruction require the ability to look up
these names. Note that various kinds of macros can introduce unique
names, and update the name lookup facilities for macro-generated names
to account for them.
Fixes rdar://106053984.
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
The _Copyable constraint was implemented as a marker protocol.
That protocol is part of the KnownProtocol's in the compiler.
When `ASTContext::getProtocol(KnownProtocolKind kind)` tries
to find the ProtocolDecl for Copyable, it will look in the
stdlib module (i.e., Swift module), which is where I initially
planned to put it.
That created problems initially when some regression tests
use `-parse-stdlib` failed to do that protocol lookup, which is
essential for adding the constraint (given the current implementation).
That led to believe we need to pull Copyable out of the stdlib, but that's
wrong. In fact, when building the Swift module itself, we do `-parse-stdlib`
but we also include `-module-name Swift`. This causes the _Copyable protocol
defined in the Stdlib to be correctly discovered while building the stdlib
itself (see the test case in this commit). So, the only downside of
having the Copyable protocol in the Stdlib is that `-parse-stdlib` tests
in the compiler can't use move-only types correctly, as they'll be
allowed in generic contexts. No real program would build like this.
Until I have time to do a further refactoring, this is an acceptable trade-off.
fixes rdar://104898230
This adds a new `primary_file` key, which defaults to `sourcefile`. For
nested expansions, `primary_file` should be set to the containing file
and `sourcefile` to the name of the macro expansion buffer.
Previously enum AccessLimitKind was
added to distinguish access scopes b/t package and public while keeping
DeclContext null but it proved to be too limiting. This PR creates package specific entries for DeclContext and
ASTHierarchy. It create a new class PackageUnit that can be set as the parent DeclContext of ModuleDecl. This PR
contains addition of such entries but not the use of them; the actual use of them will be in the upcoming PRs.
Resolves rdar://106155600
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.
