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
...rather than by whether they're implicit. We're planning to make
them explicit (prompted by a change in upstream Clang that no longer
prints implicit attributes).
rdar://problem/40346997 (Swift side)
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
...instead of relying on the one in the overlay in pre-4.2 versions of
Swift. This caused crashes in deserialization, which (deliberately)
doesn't respect availability.
There are three changes here:
- Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay.
- Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from
the underlying UIKit framework. (This is the nested name.)
- Ignore the unavailability messages for those two constants in
pre-4.2 Swift, since we're now relying on them being present.
The latter two, the compiler changes, can go away once UIKit's API
notes no longer specify different pre-4.2 behavior, but meanwhile we
need to keep compatibility with the SDKs released in Xcode 10b1.
https://bugs.swift.org/browse/SR-7879
If the Clang declrations are *types*, canonical declaration in Swift is
imported for newest version of Swift. In interface generation, if the
declaration is versioned and it's imported as a member in either or both
version of Swift, we have to take compatibility typealias into account.
* Fixed 'ClangModuleUnit::getTopLevelDecls' to take isCompatibilityAlias() into account
* Fixed bugs in ClangImporter where member-to-member versioned types aren't properly imported.
* Fixed 'SwiftDeclConverter::importFullName' to check equality of getEffectiveContext()
* Fixed 'importer::addEntryToLookupTable' to check equality of getEffectiveContext()
(moved 'ClangImporter::Implementation::forEachDistinctName' to 'NameImporter')
Still to do: test and fix up the use of multiple enum_extensibility
annotations, possibly with API notes. This is important because the
definition of NS/CF_ENUM /includes/ enum_extensibility(open) as of
Xcode 9.0; there should be a convenient out people can use to declare
exhaustive enums in C that's backwards-compatible.
Swift's ASTContext contained all of the logic to find the complete list
of properties for an Objective-C class, which is used by the Clang importer
to influence the mapping of Objective-C names into Swift. Swift's
ASTContext also included a *cache* for this information, indexed by
the Clang `ObjCInterfaceDecl *`. However, this cache was getting
populated/queried from the Clang importer's name importer, such that
the keys would be Clang declarations used to build modules and then
deallocated. If that memory eventually gets reused for a different
`ObjCInterfaceDecl *`, we would get incorrect/stale all-properties
information.
Almost Surely fixes rdar://problem/35347167, which is a
nondeterministic failure where UIView's `addGestureRecognizer(_:)` gets
occasionally imported as `add(_:)`.
*** Depends on Clang change "[APINotes] Record what version caused ***
*** an annotation to get replaced." Update your Clang checkout! ***
More generally, change the meaning of the SwiftVersions section in API
notes to be "this version or earlier" rather than "exactly this
version". We mostly get this behavior for free from the Clang-side
changes, but for SwiftName and the enum annotations we look at inactive
attributes as well. The latter is simple, but the former means being
careful about finding the annotation we /would/ have picked, i.e. the
one closest to the version we requested.
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
Preparation for making ImportNameVersion a generalized struct rather
than an enum. We could have kept cramming it into a bitfield, sure,
but we don't actually need this.
No intended functionality change.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
This would fail later down the line anyway, meaning this does not
change the ultimate behavior of the importer, but since I added an
assertion that we're expecting a definition here in 2c68f8d49d, we
need to avoid even asking the question.
Also fix up a few other places where we aren't sure we'll have a
definition when calling these functions.
rdar://problem/33784466
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Also lays the groundwork for rdar://problem/16513537, which is about
being able to find an enum by its original top-level name so that we
can show a diagnostic for that. I'll file a public bug about that
later.
rdar://problem/31893305
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in
both. This allows the compiler to produce sensible errors and fix-its
when someone uses the "wrong" name for an API. The diagnostics
certainly have room to improve, but at least the essentials are there.
Note that this commit only addresses /top-level/ decls, i.e. those
found by lookup into a module. We're still limited to producing all
members of a nominal type up front, so that'll require a slightly
different approach.
Part of rdar://problem/29170671
The next commit will make findSwiftNameAttr handle Swift 3 / Swift 4
API notes, so it's important that everything is consistently using it.
(The other place that isn't updated yet is enum info; conceivably, the
prefix for enum constants might be different based on which
SwiftNameAttrs are in play.
Extensive cross-language tooling support needs to bridge decl names between two different languages more freely. This SourceKit request is designed to translate Objc names to Swift names and vice versa. Working similarly to cursor-info requisition, the name translation request requires a Swift reference to a Swift/Clang decl, and the preferred name to translate from, and language kind that the given name belongs to. If the translation succeeds, SourceKit service responds with the corresponding name than belongs to the other kind of language.
Newly introduced keys:
“key.namekind": “source.lang.name.kind.objc” | "source.lang.name.kind.swift"
“key.basename”: “name"
“key.argnames”: [“name"]
“key.selectorpieces”: [“name[:]"]
This commit only implements translation from Objc to Swift.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Remove all occurrences of a "useSwift2Name" bool, and replace it with
version plumbing. This means that ImportDecl is now entirely
version-based, and the importer Impl knows versions. This will be
needed for marking Swift 3 names as deprecated, when there is a new
Swift 4 name.
NFC.
Expose a ForeignErrorConvention::Info struct, so that the
ClangImporter can also utilize this space-efficient
storage. Eliminates the ClangImporter's ad-hoc representation, and
shaves off a pointer or so off of the ImportedName size.
While we're out it, make some of the bools bitfields to shave off
another pointer in size. Total ImportedName size is now 6.
Shave off a pointer from the EffectiveClangContext, by re-arranging
some of its data. Down to 2 pointers from 3.
Inside of ImportName, factor out the does-it-have-a-value from
multiple stored Optionals so as to shave off a couple of
pointers. Present the same programming interface as before. Down to 8
pointers in size from 10, and still much further to go.
Change the interfaces to ImportedName to be method based, rather than
direct struct field accesses. We're going to be changing how these are
used in the future. Also, we will be storing large quantities of
these, so we will soon want to crunch down on their size.
