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
NormalProtocolConformance::isRetroactive() introduces dependency on swiftClangImporter by calling ClangModuleUnit::getAdapterModule().
Do some refactoring to break the cycle.
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.
- Use the name for the cached module, so that we don't end up with a
zillion "x86_64-XXXXXXXX.swiftmodule" files in the cache when we're
working with architecture-specific swiftmodules.
- Diagnose if the expected name is different from the name specified
in the swiftinterface.
- Emit all diagnostics at the location of the import, instead of
without any location at all.
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.
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
Looking these up is slow because the attribute lists get rebuilt and
reuniqued in the LLVM context each time. Saving them is a single
pointer per IntrinsicInfo and IntrinsicInfos are already cached in
each SILModule.
This shaves about 4s off optimizing the standard library (72s out of a
3:00+ build), and probably has much less effect anywhere else. That
is, it's not /really/ important after all, but it was an easy bit of
the profile to hammer down.
Use the Dependencies map to standardize on a single allocation for
any particular Request. We could probably go all the way to unique
ownership here, but I didn't want to rock the boat.
Results in minor speedups compiling the stdlib. (I was experimenting
with using a new, auto-cached Request for a hot lookup path, which may
or may not turn out to be worth it, but even without that we can take
this.)
* Remove apparently obsolete builtin functions.
- Remove s_to_u_checked_conversion and u_to_s_checked_conversion functions from builtin AST parsing, SIL/IR generation and from SIL optimisations.
* Remove apparently obsolete builtin functions - unit tests.
- Remove unit tests for SIL transformations relating to s_to_u_checked_conversion and u_to_s_checked_conversion builtin functions.
* Remove apparently obsolete builtin functions.
- Remove s_to_u_checked_conversion and u_to_s_checked_conversion functions from builtin AST parsing, SIL/IR generation and from SIL optimisations.
* Remove apparently obsolete builtin functions - unit tests.
- Remove unit tests for SIL transformations relating to s_to_u_checked_conversion and u_to_s_checked_conversion builtin functions.
When the Clang importer imports the components of a C function pointer
type, it generally translates foreign types into their native equivalents,
just for the convenience of Swift code working with those functions.
However, this translation must be unambiguously reversible, so (among
other things) it cannot do this when the native type is also a valid
foreign type. Specifically, this means that the Clang importer cannot
import ObjCBool as Swift.Bool in these positions because Swift.Bool
corresponds directly to the C type _Bool.
SIL type lowering manually reverses the type-import process using
a combination of duplicated logic and an abstraction pattern which
includes information about the original Clang type that was imported.
This abstraction pattern is generally able to tell SIL type lowering
exactly what type to reverse to. However, @convention(c) function
types may appear in positions from which it is impossible to recover
the original Clang function type; therefore the reversal must be
faithful to the proper rules. To do this we must propagate
bridgeability just as the imported would.
This reversal system is absolutely crazy, and we should really just
- record an unbridged function type for imported declarations and
- record an unbridged function type and Clang function type for
@convention (c) function types whenever we create them.
But for now, it's what we've got.
rdar://43656704
Closures can't explicitly capture a mutating self parameter, so
let's re-word diagnostic to point what what actual problem here
is, and add a note about ways to fix the code.
Thanks to Cory Benfield for message suggestion.
Resolves: [SR-9314](https://bugs.swift.org/browse/SR-9314)
Resolves: rdar://problem/46322943
Remove the unnecessary use of the positional arguments in the diagnostic
formatting. This is not portable as it is a SUS extension and the Microsoft C
runtime does not support this extension.
