This functionality doesn’t really change what we accept right now, because we eagerly import all of the methods of a class when we do *any* kind of lookup into the class. However, when we manage to stop doing that, this operation will become more important.
Swift SVN r23289
Also, remove calls to isSwiftReservedName in
ClangImporter::Implementation::importName(), since 'true' and 'false'
are now keywords and rdar://problem/13187570 is no longer a problem.
rdar://problem/18797808
Swift SVN r23244
The ClangDiagnosticConsumer forwards diagnostics from Clang's diagnostic machinery
to Swift's. It deliberately filters out things that happen in our top-level dummy
buffer (usually trivial things like "module imported here"). Unfortunately, it was
doing so by checking against the current SourceManager's "main file". When building
Clang modules (compiling PCM files), we're dealing with a new SourceManager, whose
main file is the module map file.
Instead, just check against the (very unlikely) name of our dummy input file,
like we do for imported headers.
rdar://problem/18867749
Swift SVN r23121
Previously we hardcoded a few important default CPUs, ABIs, and features into
Swift's driver, duplicating work in Clang. Now that we're using Clang's
driver to create the Clang "sub-compiler", we can delegate this work to Clang.
As part of this, I've dropped the options for -target-abi (which was a
frontend-only option anyway) and -target-feature (which was a hidden driver
option and is a frontend-only option in /Clang/). We can revisit this later
if it becomes interesting. I left in -target-cpu, which is now mapped
directly to Clang's -mcpu=.
Swift SVN r22449
This is most important for -Xcc options, which shouldn't be dependent on
the underlying Clang version, but it also affects things like target features
that Clang knows how to compute correctly and Swift, well, doesn't.
rdar://problem/17687572
Swift SVN r22448
- Merge availability info by merging CommonEntityInfo as part of ObjCContextInfo.
- Don't try to add Absent nullability to property setters (since it cannot be
represented by ObjCMethodInfo).
- Factor out lookupObjCContext and make sure we always look up in both
class and protocol.
This will be tested by API notes drop, which will get committed separately.
Swift SVN r22089
Some of the buffers are owned by the ClangImporter, so after the
ClangImporter's been deallocated, the SourceManager isn't going to be fully
valid any more.
Should fix issues from r21958.
Swift SVN r21989
Removes the initWithBool: hack from the Clang importer. We can now
express NSNumber's conformance to the BooleanLiteralConvertible
protocol in the overlay.
Swift SVN r21976
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
Once can use ClangModuleLoader::getImportedHeaderModule() to check if the module is the importer-header module.
This reverts commit r21949.
Swift SVN r21955
We don't do this very efficiently, but it does work. And now that it's working,
drop some special cases in module interface printing -- just always print
Clang decls in Clang source order.
Swift SVN r21901
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
This is a hack that allows us to support accessibility APIs in Swift.
It addresses radar://17509751.
A class might conform to both NSAccessibility (containing accessibility
properties) and individual accessibility protocols (containing
accessibility methods with the same names as the properties). This should
not compile (but currently happens to compile). To avoid the problem down
the road, we import setters and getters instead of the accessibility
properties from NSAccessibility.
Swift SVN r21757
I'm not quite sure how to tickle this one, but the next commit adds more
data after the cached header, at which point existing tests break. This
could have already caused problems if no padding was needed in the bitstream.
Swift SVN r21543
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
This regresses a bit on the diagnostic when a submodule is missing, as well
as missing out on Clang's automatic typo correction, but it does avoid putting
the Clang CompilerInstance into an error state, which is important for the
REPL. It's also not entirely clear that Clang had the right behavior in this
case either---we'd get a module back, but if the particular submodule we
asked for didn't exist we might get its parent. We can revisit this later.
Prerequisite for <rdar://problem/17994094>.
Swift SVN r21333
i.e. don't look for attributes on an @class somewhere.
Also do this for tag decls, whose attributes propagate forwards until there's
a definition.
<rdar://problem/17986861>
Swift SVN r21223
This makes sure that the Clang CompilerInstance doesn't think that we've seen
an error just because we were checking for the existence of a module, and
therefore will not break the world when the module is absent.
This fixes an issue where loading PlaygroundLogger broke static inline
functions because PlaygroundLogger has no Objective-C module.
<rdar://problem/18007508>
It also lays groundwork for not treating a missing module as a fatal error
in REPL modes. To do that properly, however, we should figure out how to do
this for submodules as well. <rdar://problem/17994094>
Swift SVN r21187
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
Background: if a Clang module /only/ imports submodules from another module,
we would lose all re-exports from that other module, because we're treating
all decls as part of the top-level module. This actually shows up with UIKit
and QuartzCore due to some weirdness in how the QuartzCore module is set up
(see <rdar://problem/17888079>), resulting in 'CALayer' not being visible
with just 'import UIKit'.
Workaround (this patch): treat Clang imports just like Swift imports: if the
submodule is referenced, so is the top-level module. This isn't great, but
it's not really any more awful than the rest of our Clang modules story.
<rdar://problem/17607060>
Swift SVN r20920
This is already a fatal error, so it doesn't matter how many diagnostics we
dump after that. It's better not to lie to the rest of the compiler about
whether the load succeeds.
No immediate Radar, but this fixes a crash in the test case I'm about to
commit, and possibly some other mystery "dependency missing" crashes in
XREF resolution.
Swift SVN r20919
