Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
When expanding a Swift macro in a clang module where the original clang
module imported a submodule in a C++ standard library module other than
`std`, e.g. a submodule to `std_core`, this would result in an error.
This is because `std_core.math.abs` would be imported as
`CxxStdlib.math.abs`, which would later be translated back as
`std.math.abs` which doesn’t exist.
This changes the mapping to only map `std` to `CxxStdlib`. To prevent
errors when importing modules starting with `std_`, this error is moved
from the late-stage module import to the earlier processing of
`ImportDecl`s. This results in these module names still being forbidden
in explicit imports (i.e. naming them in source code), while still being
allowed in implicit imports inherited from clang modules.
This also fixes a fix-it bug where only the first 3 characters would be
selected for replacing with `CxxStdlib` when importing `std_core`.
This also fixes a diagnostic bug where aliased modules would refer to
the module name in the source code rather than the real module name, and
adds a note clarifying the situation.
rdar://161795429
rdar://161795673
rdar://161795793
fix non-fatal import error
```
lib/Index/Index.cpp:137:41: warning: returning address of local temporary object [-Wreturn-stack-address]
lib/Sema/ImportResolution.cpp:627:9: warning: 'AttributedImport' may not intend to support class template argument deduction [-Wctad-maybe-unsupported]
```
When using an internal import for a bridging header, semantically treat
the contents of the bridging header, and anything that it imports, as
if they were imported internally. This is the actual semantic behavior
we wanted from internally-imported bridging headers.
This is the main semantic checking bit for rdar://74011750.
An assert checking the invariant of the module passed to
alreadyImportedTLM being a top-level module would dereference a null
pointer in the case where the clang module contained syntax errors,
since findUnderlyingClangModule would return null. Instead call the
bespoke isSubmodule function that already performs this null check.
This fixes the lldb test
lldb/test/API/lang/swift/clangimporter/expr_import/TestSwiftExprImport.py.
Limit reporting as an error imports of a non-library-evolution module
from a library-evolution enabled module to sources that are part of the
SDK. The error also requires having enabled `InternalImportsByDefault`.
This should help prevent SDK breaking regressions while loosening the
restriction elsewhere.
Framework owners can enable `-library-level api` or `spi` to get this
check as an error, along with more sanity checks.
Other cases remain as a warning. We should look to silence it in some
cases or offer a flag to do so.
rdar://160414667
Contents in namespaces are imported to the bridging header module
`__ObjC`. When macros attached to a decl imported from a namespace are
expanded, they also end up in `__ObjC`. This prevents them from
inheriting imports from the module they originated in. This patch
implements a workaround by adding an alternative constructor to
`ImportResolver` that takes an explicit origin module as input,
overriding which module counts as the "parent" module.
This fixes a few tests that were failing because scoped imports were
counted as having imported the module already, leading to later imports
of the same module being skipped. Since the scoped imports don't import
the full module, this would result in syntactically imported symbols not
being found by the compiler.
There's only one caller to performImportResolutionForClangMacroBuffer,
which always passes a newly allocated SourceFile. This removes a
redundant check for whether its imports have been resolved, and instead
asserts that they haven't.
Importing clang submodules results in an implicit import of the
top-level module as well. This can result in the same TLM being imported
many different times, if multiple submodules are imported from the same
module. This deduplicates these imports.
Other imports are not expected to be duplicated, so care is taken to
only deduplicate clang TLM imports.
When macros like _SwiftifyImport are added to a wrapper module for a
clang module, they may need to refer to symbols declared in another
clang module that the wrapped module imports (e.g. because they are used
in the original signature). This adds all the imported clang modules as
implicit imports to the wrapper module.
rdar://151611573
Lookup into C++ namespaces uses a different path from C++ record declarations.
Augment the C++ namespace lookup path to also account for the auxiliary
declarations introduced by peer macro expansions.
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
C++ swift::Parser is going to be replaced with SwiftParser+ASTGen.
Direct dependencies to it should be removed. Before that, remove
unnecessary '#include "swift/Parse/Parser.h"' to clarify what actually
depends on 'swift::Parser'.
Split 'swift::parseDeclName()' et al. into the dedicated files.
The `_Concurrency` module imports a C module that is not available in the
toolchain or SDK, which means that `@_implementationOnly` must be used to hide
the dependency on this module from clients.
Preserve the warning to use `internal import` instead of `@_implementationOnly`
to imports of Swift modules only. This warning can be noisy, limiting it may
prevent users from outright learning to ignore it. Typical uses of an
`@_implementationOnly` import of a clang module is often for a project
internal module instead of a layering concern as we have with Swift module
targets. We can leave legacy uses of `@_implementationOnly` in peace for now.
The warnings about `using '@_implementationOnly' without enabling library evolution for 'client'
may lead to instability during execution` and `@_implementationOnly' is deprecated, use
'internal import' instead` were wrongly restricted to only Swift import targets.
Make sure they are raised for clang module targets as well.
rdar://135233043
Add support for access-level on imports and `@_spiOnly imports` to cross
import overlays. The overlay inherits the most restrictive import
access-level of the declaring module and the bystander module.
rdar://129606112
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Silence errors on ambiguous implicitly public imports when a different import
is explicitly public. In this case all imports are public so the ambiguity is
not dangerous and this configuration can happen during adoption of
access-levels on imports. Keep the error when an explicit import is package,
internal or below.
rdar://129037503
Adoption InternalImportsByDefault provides a safe access-level by default
to imports, as such ambiguities are not a risk and showing this warning is
superflous. When this warning is shown, make sure we note this alternative.
Report uses of `@_implementationOnly` in resilient modules as deprecated.
With a fixit to replace it with `internal` or delete it when imports
are internal by default.
Uses of `@_implementationOnly` in non-resilient modules is already reported
as being unsafe.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
By default package decls are treated as resilient, similar to public (non-frozen).
This PR adds support to allow direct access to package decls at use site if opted-in.
Requires the loaded module to be a binary module in the same package.
Resolves rdar://121626315
In Swift 5 mode, the compiler reports when two files import the same
module, where one file has a bare import and the other an access-level
import. This avoids unintentionally promoting the import to public when
preexisting code marked it otherwise.
Exempt a file generated by Xcode from this check as it's not user
modifiable.
In the future, we should identify such generated files properly. Either
with a new attribute or in the way they are passed to the compiler.
rdar://122032472
As recommended in feedback on https://github.com/apple/swift/pull/71302, cache
the underlying clang module after loading it in `ImportResolver`, rather than
filtering it out of the overall set of resolved imports. This is more efficient
and results in less duplicated code that must identify the underlying clang
module.
The correct use @_implementationOnly from a non-resilient module is not
enforced by the compiler at this time. Using that configuration can
cause memory corruption at runtime if it affects the memory layout of
types, and it can lead to compiler crashes at compilation in general.
Some modules rely on this configuration with a very limited use for it.
We can grandfather them in its use and silence the warning on specific
import edges.
