Otherwise, we crash later in code that assumes the presence of a
generic parameter list implies the presence of a generic signature
(and vice versa).
Fixes <rdar://problem/46604393>.
Diagnostics could introduce type-checked expressions into AST during
it's bottom up re-typechecking in attempt to find a problem.
To minimize number of AST permutations solver has to handle
let's just strip away implicit `InOutExpr` introduced by previous
successful type-checks, which is not really important anyway.
Resolves: rdar://problem/46459603
Previously if a declaration had both a Type and a TypeRepr available,
we would only check the access of the TypeRepr. However, this is
incomplete when the type is partially inferred, as in
public var inferredGenericParameters: Optional = PrivateStruct()
The new algorithm is to the Type first, then:
- if the Type is okay, move on to check the TypeRepr
- if the Type is not okay and we're in pre-Swift-5 mode, check the
TypeRepr, and if /that's/ okay downgrade the whole thing to a
warning.
Unfortunately, we can't /just/ check the Type in the "good" case,
because we don't always properly preserve sugar when going from a
TypeRepr that represents a typealias to the corresponding Type, and we
want to be able to fix those cases in the future. So we have to check
both.
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
Validating a declaration can trigger conformance checking. If the conformance checker
comes across the same declaration as a candidate witness, it would fail to emit a
diagnostic. As a result we would then go onto SILGen, which would crash while emitting
a witness table with a missing entry.
Fixes <rdar://problem/45151902>.
If we computed captures before completing a lazy getter body, we would fail to
consider the 'self' capture properly. Instead make it resilient to such ordering
issues by checking in capture computation if the lazy property has a getter yet
or not.
This patch mainly consolidates the functions used to check accessors vs.
other decls, and makes sure we check setter access as well as regular
decl access.
rdar://45217648
AST/LookupVisibleDecls.cpp has a dependency on swiftSema by having doGlobalExtensionLookup call into swift::isExtensionApplied,
and doGlobalExtensionLookup is ultimately used by the other global functions in that file.
Break the cycle by moving the file into the swiftSema library.
When an on-demand accessor is synthesized while checking a conformance,
make sure it ends up in the 'external declarations' list so that SILGen
can emit it.
Fixes <rdar://problem/46503121>, and part of <rdar://problem/46186045>.
While trying to lookup member reference on some base type, handle
base being an `InOutType`, which could be a result of previous
sub-expression re-typechecks made by diagnostics.
Resolves: rdar://problem/45771997
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
SE-206 deprecated hashValue as a protocol requirement. We should gently encourage people to migrate to hash(into:), for its more secure, easier and faster hashing.
Emit a compiler warning whenever hashValue has an explicit implementation, but hash(into:) doesn’t.
Detect and fix situations when (force) unwrap is used on
a non-optional type, this helps to diagnose invalid unwraps
precisely and provide fix-its.
Resolves: [SR-8977](https://bugs.swift.org/browse/SR-8977)
Resolves: rdar://problem/45218255
The attempt to short-circuit wiring up generic parameters of a context
didn’t work when one of the inner types didn’t itself have generic
parameters. Make sure we still wire up generic parameters in this case.
Fixes a crasher encountered while investigating rdar://problem/43406595.
Under -debug-generic-signatures, we were computing and emitting
conformance access paths for one test. Given that conformance access
paths are used ubiquitously now, this test isn't providing any value
(nor is the debug dump), stop dumpoing them.
If the base type is not optional, trying to unwrap it is
incorrect. Introduce a fix to make it look like base was
an optional type which leads solver to move forward
towards possible solution.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
When parameter refers to something undefined its type is going to
be `ErrorType`, so diagnostic path needs to make sure that parameter
has a valid function type before trying to extract result from it.
Resolves: rdar://problem/46377919
