Similar with @keyword, manifesting @recommended and @recommendedover content in code
completion results can help IDE users to choose the right API in the long candidate list.
This commit extract these two attributes from Clang doc comments and insert/cache them in
code completion results.
rdar://23101030 and rdar://23101029
Conventionally, code completion results are matched with user input solely by
names. However, names are limited in expressiveness. From this comments, we start to
decorate code completion results with @keywords fields extracted from Clang doc comments.
These fields are added by API authors to comment the decl with information that
is not manifested clear enough through names. Code completion users' typing of the
keyword leads to the corresponding code completion results being selected as well.
Keywords can be arbitrarily long and can be multiple.
For instance, a function called "index()" has "@keyword find" in its doc comment.
Users' typing of "find" leads to "index()" being selected in the code completion list.
...and add one extra check for invalid macro info.
This reinstates the tests that were disabled in my previous commit, now that the
Clang issue has been fixed.
Finishes rdar://problem/21480635.
Patch by Jordan Rose.
Swift SVN r29705
This was broken in upstream Clang (LLVM PR23929). When it's fixed, this commit
should be reverted to restore all the disabled tests. See rdar://problem/21480635.
Patch by Jordan Rose.
Swift SVN r29704
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
This reverts commits r26369 & r26381.
After upstream clang changes, reverted r25843 which was compensating for a previous upstream clang change.
But keep test/IDE/complete_from_clang_framework.swift disabled for further investigation, because it
seems to have some duplications in a code-completion test.
rdar://20245658&20247922
Swift SVN r26430
Move the availability printing tests from IDE/print_clang_decls.swift to
IDE/print_clang_framework.swift (which is only run on OS X). This commit should unbreak
the iOS build bots, which I broke in r24973.
This commit does not address Jordan's concerns with the tests. I will do that in a latter
commit.
Swift SVN r24985
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
We can't reliably reject raw values in an NS_ENUM's init(rawValue:), because the enum may have SPI or future values we don't statically know about. Fixes https://twitter.com/autorelease/status/524698585406124033
Swift SVN r23817
If an imported C struct has no __nonnull pointer fields, then we can give a default initializer that zeroes all of its fields. This becomes a requirement when working with partially-imported types like NSDecimal. NSDecimal has bitfields Swift can't see yet, so it's impossible to DI, but the Foundation functions that work with NSDecimal all emit their result by out parameter, and without access to its fields it is impossible to initialize an NSDecimal for use with one of these functions. Implement the initializer using a builtin that gets lowered by IRGen; this is also made necessary by the fact that Swift has only a partial view of the struct, so we can't form a complete zero initializer until we have the definitive type layout from Clang.
Swift SVN r23727
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
- Make NSZone functions unavailable radar://16688847
- Distributed Objects subsystem should not be imported into Swift radar://16689104
- NSCalendarDate is available in Swift, but deprecated radar://16689207
- Do not import NSMethodSignature class and related methods radar://16689329
- NSInvocationOperation should be unavailble in Swift radar://17921785
Swift SVN r22090
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
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
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
Previously we only printed submodules that were imported by the
top-level module, which worked in the common case of inferred submodules
of frameworks (e.g. Foundation.NSArray), but fell over when the
submodules were explicit (e.g. OpenGL.GL), or just not imported by the
top-level module.
Swift SVN r20855
We require some level of consistency between the way the overlays were
built and what we work with in our mock SDK. The IDE/sdk_sugar.swift
test failure was because the overlay referenced "init(coder:)" while
the test was looking for "init(withCoder:)". Hilarity ensued
<rdar://problem/17791048>.
This only impacts testing.
Swift SVN r20564
