LLVM r336847 changed FileCheck's CHECK-DAG feature to stop supporting
overlapping matches. I already fixed one test by invoking FileCheck with the
-allow-deprecated-dag-overlap option, but it turns out there are a bunch
more of them. This change applies the same workaround to all of them.
We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
* Make FloatingPoint require that Self.Magnitude == Self
We didn't have the where clause to express this constraint at the time that the FloatingPoint protocol was implemented, but we do now. This is not a semantic change to FloatingPoint, which has always bound IEEE-754 arithmetic types, for which this constraint would necessarily hold, but it does effect the type system.
For example, currently the following function does not type check:
~~~~
func foo<T>(x: T) -> T where T: FloatingPoint {
var r = x.remainder(dividingBy: 1)
return r.magnitude
}
~~~~
with this change, it compiles correctly.
Having done this, we no longer need to have a separate `abs` defined on FloatingPoint; we can use the existing function defined on `SignedNumeric` instead. Additionally mark the global `fabs` defined in the platform C module deprecated in favor of the Swift `abs`; we don't need to carry two names for this function going forward.
Calling '@objc optional func' requires '?' or '!' after its name. When
completing method calls for them, 'key.sourcetext' should have '?'
whereas 'key.name' shouldn't.
Note that we deliberately do not use optional type name for
'key.typename'. This is consistent with optional chain '?.<propertyName>'
behavior.
rdar://problem/37904574
This is our first statement attribute, made more complicated by the
fact that a 'case'/'default' isn't really a normal statement. I've
chosen /not/ to implement a general statement attribute logic like we
have for types and decls at this time, but I did get the compiler
parsing arbitrary attributes before 'case' and 'default'. As a bonus,
we now treat all cases within functions as being switch-like rather
than enum-like, which is better for recovery when not in a switch.
Adds a -working-directory option which can be used to modify how
relative paths are resolved. It affects all other paths used in driver
options (controlled by a new ArgumentIsPath flag on options) as well as
the contents of output file maps and auxilliary file paths generated
implicitly by the compiler itself.
rdar://37713856
These tests were relying on sourcekitd parsing as frontend instead of
using the driver. Update them now to avoid churn when we fix command
line argument parsing in sourcekit.
The changes from clang-importer-sdk to clang-importer-sdk-nosource -I %t
are because clang-importer-sdk implies using -enable-source-import.
Rather than hack them up to use -Xfrontend, it is cleaner to just stop
using source import at all for these tests. Incidentally, this improved
fidelity in a few places. When using the generated swift modules we
also need to pass a target triple to sourcekit, which exposed some tests
that had mac-specific data. This is a systemic issue for sourcekit
tests, but for now just make those few specific tests that we had
problems with run only on mac.
When completing
Foo(<here>
We will now provide
bar: <#value#>
instead of
bar: <#value#>)
Inserting the rparen caused some problems in practice:
* the old behaviour optimized for typing Foo(<complete> instead of
Foo(<complete>), which can conflict with user behaviours or ...
* in editors with automatic brace-matching, we often conflicted with the
editor, leading to extraneous closing parens
And in general, it is much more predictable for tooling to either insert
matching ( and ) or to not insert either. While this change may not be
ideal For users of editors that do not do automatic brace-matching, I
believe it is still better overall to have to type a missing paren than
to have to delete an extraneous one.
rdar://31113161
The original hope was we could make these heuristics really good, but
since that is not currently in sight (and may never be), we want to be
able to turn them off. For now, just plumb through an internal flag to
control the behaviour. A future change will customize the behaviour in
SourceKit.
rdar://31113161
With broken code you can end up with non-postfix completions when
searching for inner operators, which you never want because you end up
creating compound results like "fooUIColor".
rdar://problem/34145229
When completing in an if/while/guard statement condition that expects a
boolean, add the code-completion type relation for Bool. We already had
this for repeat-while.
rdar://problem/26509084
For normal completions it behaves the same as PostfixExprBeginning, but
it provides a hook for clients to provide a custom completion for this
position. For example, you might want to a x ..< y snippet in this
position.
rdar://problem/29910383
When using completion options that will allow the lone "." completion,
provide that result when in contexts that expect an enum type. Note:
this is a crappy approximationg for whether the type can have "implicit
member expression" syntax, since uninhabited enums should not support
it, and many non-enum types should. However, it is currently expensive
to compute the accurate answer and this approximation is good enough for
some clients.
rdar://problem/31260505
The filter name isn't helpful if you want to make rules about specific
overloads - e.g. only show the [Int] subscript on Array.
rdar://problem/28920034
`FreeTypeVariableBinding::GenericParameters` mode allowed to bind
all free type variables with fresh generic parameter types, which
is incorrect (at least) if there are multiple generic solutions
present, because such parameters couldn't be compared.
This mode was used for code completion, which is now switched to use
`FreeTypeVariableBinding::UnresolvedType` instead.
We don't care what the USRs are here, we were just using them to avoid
results slipping in between the start of the structure and the module
name. This patch does that in a way that doesn't use the USR.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
* If "required" or "convenience" is specified, emit only initializers
* If "final" or "open" is specified, don't emit initializers or typealias
* If "typealias" is specified, emit only associated type implementation
* Emit "override" or "required" modifier for initializers
* Emit access modifier for initializers
* Emit designated initializers even if "override" is specified
* Don't emit inheritance clause for associated type implentation
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
The high weight on semantic context turns out to give a lot of
unreasonable completions on common types. For example
[0].ma<here>
was suggesting withUnsafeMutable... over map.
rdar://problem/27393776
Right now 'fileprivate' is parsed as an alias for 'private' (or
perhaps vice versa, since the semantics of 'private' haven't changed
yet). This allows us to migrate code to 'fileprivate' without waiting
for the full implementation.
