- Make sure VarDecls have an associated TypeLoc, like ParamDecls do, then use it for printing the VarDecl's type.
This is done by moving ParamDecl's TypeLoc up to the VarDecl.
This is useful for being able to display the parameter names of function types embedded in VarDecls.
- Use the result TypeLoc of functions for printing. This enables printing parameter names of function types embedded in return types.
- Make sure to annotate attributes while they are printed.
...to value types. Do continue bridging BOOL to Bool and such.
If the Objective-C API author went out of their way to indicate
ownership, they're probably using the reference semantics for
something. Give them the benefit of the doubt and leave the properties
declared using reference types. (It's not that they wouldn't work
correctly using Any, but that it's obscuring the intended interface.
And any /specific/ bridged value types /might/ actually cause issues
by causing copies.)
There is one wrinkle here involving declarations in the "accessibility
protocols" on Apple platforms, which sometimes use methods and
sometimes properties. The Swift compiler already deals with these by
always importing these as methods, so treat these like any other
methods and use value types when relevant.
rdar://problem/27526957
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
Error domain enums are imported with synthesizing something like this:
struct MyError {
enum Code : Int32 {
case errFirst
case errSecond
}
static var errFirst: MyError.Code { get }
static var errSecond: MyError.Code { get }
}
The clang enum and enum constants are associated with both the
struct/nested enum, and the static vars/enum cases.
But we want unique USRs for the above symbols, so use the clang USR
for the enum and enum cases, and the Swift USR for the struct and vars.
rdar://27550967
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
Showing only the conforming associated types provides
little information to doc viewers. This patch digs the
underlying type of an associated type to report the
conformance info of those.
Addresses SR-1509 by adding a heuristic to import numeric literals with a
type cast. Two new cases have been added for macros with 4 or 5 tokens
to cover cases with or without sign tokens.
* A bunch of them require objc_interop because they import code containing
Objective-C.
* Many others fail on Ubuntu 14.04 because the C++ there doesn't have a
functional std::regex implementation which is required by the
`complete-test` tool.
It may be possible to adjust some of these tests in the future to not
need these extra requirements, but this is a straightforward way to
clean up Linux test results for now.
This started failing after one of the two commits:
[stdlib] Add missing discardableResult attribute
Fixes SR-1695: Option Set insert needs @discardableResult
[gardening] Remove unused diagnostic
attr_warn_unused_result_mutable_variable
These commits seem harmless so I disabled the test pending further
investigation.
rdar://26718415
In addition to a new test fixture for 'SourceKit/DocSupport/
doc_clang_module.swift', this removes the check for an ASCII-only
generated standard library interface from 'SourceKit/InterfaceGen/
gen_stdlib.swift'.
Previously we imported a Core Foundation type "CCFooRef" as "CCFoo",
but also provided a typealias "CCFooRef". In Swift 3, we decided to
mark "CCFooRef" unavailable to force developers to consistently use
"CCFoo". Now that we have infrastructure to mark /all/ renamed
declarations as unavailable, just use that to track the renaming,
i.e. pretend that "CCFooRef" was the "Swift 2" name for the type.
This doesn't change the conflict resolution behavior: if there's
another name "CCFoo" in the same module, the CF type will be
imported as just "CCFooRef".
Groundwork cleanup for rdar://problem/26347297, which notes that our
import-as-member fix-its use the "Ref" names rather than the short
names.
This revises and expands on documentation for the new collection methods
for working with indices and the revised Swift 3 set APIs. In addition,
it includes documentation for the new range types.
The Clang importer implicitly synthesizes @discardableResult for
nearly all imported functions. Printing this attribute in the
generated interface leads to a lot of noise. Mark it as implicit so we
don't print it.
Even thought raw types are specified in inheritance clauses, their
members are not usable through an enum instance. Thus, there is no
point to synthesize their members.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
The test was supposed to use a CF type, but it wasn't updated
for the switch from a naming convention to an attribute. This
restores the original intent (and unfortunately slides all the
offsets).
This reverts commit f723b86614 and
updates the IDE tests that incidentally included some punctuation.
No new tests are necessary - the character level tests are exercised
in cmark itself.
