- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Pass a wrapped VFS down into `clang::createInvocationFromCommandLine` so
that the working directory is set and then used in the underlying Clang
`CompilerInstance`.
Fixes the possibility of differing modules hashes when the same
arguments are used in Clang directly vs from the importer.
Resolves rdar://79376364
Instead of failing constraint generation upon encountering
an invalid declaration, let's turn that declaration into a
potential hole and keep going. Doing so enables the solver
to reach a solution and diagnose any other issue with
expression.
Unloaded implicit imports (e.g. the `-import-module` flag) will now be processed by import resolution, and will be fully validated and cross-imported. Preloaded imports, like the standard library import, are still not run through full import resolution, but this is a definite improvement over the status quo.
This also folds `-import-underlying-module` and `@_exported import <ParentModule>` into a single code path, slightly changing the diagnostic for a failed overlay-style underlying module import.
Move the validation of scoped imports into a
request, and force the request when we're
type-checking a primary file. This has the nice
bonus of no longer running the validation for
secondary files.
The use of `ModuleDecl::getTopLevelModule` also
allows us to correctly retrieve the top-level
module for a Clang submodule, rather than
potentially retrieving the Swift module in a mixed
source project.
Resolves SR-12265.
Christopher Rogers' (good) work in 49fd5acbb2 caught places where
the Swift compiler was allowing a @class to resolve to a Swift class
even if that class had a conflicting Objective-C name, or wasn't
intended to be exposed to Objective-C at all. Unfortunately, this
broke source compatibility in projects where people were relying on
this. Restore that functionality, but only as a fallback; matching the
Objective-C name is better than matching the Swift name.
rdar://problem/56681046
The code does naive lookup of Swift types using the type name, but sometimes the Swift type we're looking for only has that name in its @objc attribute. This change makes the compiler exclude certain Swift declarations from matching even if the Swift name is the same (namely, not being available in Obj-C or having a mismatched `@objc` name) and continue to find the correct declaration without using lookup by name.
Fixes SR-4827
...rather than replacing particular macros with an 'annotate'
attribute and then looking for that. This isn't /really/ any
particular win except maybe ever-so-slightly faster module imports
(with one fewer attribute being added to each declaration in a
mixed-source header).
This doesn't remove the SWIFT_CLASS_EXTRA, SWIFT_PROTOCOL_EXTRA, or
SWIFT_ENUM_EXTRA macros from PrintAsObjC (note that
SWIFT_EXTENSION_EXTRA was never used). They're not exactly needed
anymore, but they're not doing any harm if someone else is using them.
Now that the normal name lookup shadowing can handle the module-based
shadowing rules implemented by lookupInModule(), we can drastically
simplify the implementation, replacing the graph traversal with an
iteration over the linearized graph.
Swift handles Clang submodules as far as controlling visibility, but
pretends that all the declarations live in the top-level module for
the purposes of lookup. This was interacting poorly with another
feature: automatically importing the Swift part of a mixed-source
framework and using that as the "presentation" of a Clang module...
or a submodule in the same framework. Therefore, if you are
- compiling the Swift part of a mixed-source framework, and
- importing one of the framework's (Clang) submodules
name binding would say that the current file imports the Swift module
currently being compiled, in addition to the Clang module we actually
want. Just break the cycle in that case.
The OS sadly changes between Android ARMv7 and Android AArch64, to
avoid this and any future problems, mark the autolinking tests that
I can find with `UNSUPPORTED: autolink-extract`, which should apply
to all platforms that need autolink-extract.
This should remove these tests from failing in Android 64.
Negative tests aren't great to begin with, and this one was looking
for a pattern that could no longer happen. This particular example
doesn't seem to have regressed, but something similar has that I'm
still looking into.
This was fixed by Doug's work in e15f67e453. It isn't actually the
underlying problem in rdar://problem/43312726, but it's worth
recording the test case so we don't regress.
...even if the base decl isn't.
This isn't normally possible, but it can come up when an imported type
is import-as-member'd onto an internal Swift declaration. This isn't
even such an unreasonable thing to do, since internal Swift
declarations are exposed in the generated header for an app.
rdar://problem/43312660
The ClangImporter/MixedSource/resolve-cross-language.swift test has been
failing on master-next for a while. I filed rdar://problem/42570029 to
track fixing it, but I'm disabling it in the meantime to get the bots
passing.
This enables additional tests for the ClangImporter. This found a
missing piece in the `-enable-objc-interop` work that was done
previously. Address that and enable the tests. There are now the
following failing tests on Linux:
* sdk - depends on Foundation (not hermetic, see SR-7572)
* mixed-nsuinteger - depends on Foundation (not hermetic, see SR-7572)
* import-mixed-with-header-twice - requires apple/swift PR#16022
* can_import_objc_idempotent - requires apple/swift PR#16022
* objc_protocol_renaming - requires apple/swift PR#16022
We can use the existing logic for checking recursion in
declaration validation. This eliminates some bogus
diagnostics and allows some weird logic to be removed
from typo correction.
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
This implementation required a compromise between parser
performance and AST structuring. On the one hand, Parse
must be fast in order to keep things in the IDE zippy, on
the other we must hit the disk to properly resolve 'canImport'
conditions and inject members of the active clause into the AST.
Additionally, a Parse-only pass may not provide platform-specific
information to the compiler invocation and so may mistakenly
activate or de-activate branches in the if-configuration decl.
The compromise is to perform condition evaluation only when
continuing on to semantic analysis. This keeps the parser quick
and avoids the unpacking that parse does for active conditions
while still retaining the ability to see through to an active
condition when we know we're moving on to semantic analysis anyways.
Clang's equivalent of this is mapping fatal errors to non-fatal errors.
This isn't something we really care about for users since it's so rare,
but we do use it in our tests, like this one that's been disabled for
a long time.
rdar://problem/30287833
