Previously we would only enable by default when
`parseArgs` was called. However this wouldn't
enable it for clients such as LLDB, who provide
their own invocation. Switch the default to `true`
in the `LangOptions`, and remove some redundant
uses of `-enable-experimental-string-processing`.
The frontend flag remains, as it may be useful to
disable.
rdar://107419385
rdar://101765556
`CodeCompletioString::getName()` was used only as the sorting keys in
`CodeCompletionContext::sortCompletionResults()` which is effectively
deprecated. There's no reason to check them in `swift-ide-test`. Instead,
check `printCodeCompletionResultFilterName()` that is actually used for
filtering.
Since 865e80f9c4 we are keeping track of internal closure labels in the closure’s type. With this change, wer are also serializing them to the swiftmodules.
Furthermore, this change adjusts the printing behaviour to print the parameter labels in the swiftinterfaces.
Resolves rdar://63633158
The code assumed that if the `Type CurrentType` member was set the
`Decl *Current` member would be too. When printing the types rather than decls,
like code completion does in CompletionLookup::addTypeAnnotation(), this
doesn't always hold.
Resolves https://bugs.swift.org/browse/SR-13703
Resolves rdar://problem/70057258
Protocol extension only members are not customization point. Code
completion should not suggest them in override/conformance completion.
rdar://problem/53591636
This reverts commit 3e932c075d.
The compiler does not support @_alwaysEmitIntoClient properties
specially wrt property descriptors. The revert commit would introduce an
ABI incompatability when a keypath to Array.first is formed:
let greetings = ["hello", "hola"]
let count = greetings[keyPath: \[String].first?.count]
Runmning on an older runtime would lead to linker errors against $sSa5firstxSgvpMV
the property descriptor for Array.first.
rdar://58484319
This makes Array.first much small and more efficient.
Without this, Array.first compiled down to RandomAccessCollection.first, which ended up in pretty unefficient code.
rdar://problem/46291397
In postfix completion, for operator completion, we do:
1. Type check the operand without applying it, but set the resolved
type to the root of the expression.
2. For each possible operators:
i. Build temporary binary/postfix expression
ii. Perform type checking to see whether the operator is applicable
This could be very slow especially if the operand is complex.
* Introduce `ReusePrecheckedType` option to constraint system. With
this option, CSGen respects pre-stored types in expressions and doesn't
take its sub-expressions into account.
* Improve type checking performance because type variables aren't
generated for sub-expressions of LHS (45511835)
* Guarantee that the operand is not modified by the type checker because
expression walkers in `CSGen` doesn't walk into the operand.
* Introduce `TypeChecker::findLHS()` to find LHS for a infix operator from
pre-folded expression. We used to `foldSequence()` temporary
`SequenceExpr` and find 'CodeCompletionExpr' for each attempt.
* No need to flatten folded expression after initial type-checking.
* Save memory of temporary `BinaryExpr` which used to be allocated by
`foldSequence()`.
* Improve accuracy of the completion. `foldSequence()` recovers invalid
combination of operators by `left` associative manner (with
diagnostics). This used to cause false-positive results. For instance,
`a == b <HERE>` used to suggest `==` operator. `findLHS()` returns
`nullptr` for such invalid combination.
rdar://problem/45511835
https://bugs.swift.org/browse/SR-9061
* [stdlib] Update complexity docs for seq/collection algorithms
This corrects and standardizes the complexity documentation for Sequence
and Collection methods. The use of constants is more consistent, with `n`
equal to the length of the target collection, `m` equal to the length of
a collection passed in as a parameter, and `k` equal to any other passed
or calculated constant.
* Apply notes from @brentdax about complexity nomenclature
* Change `n` to `distance` in `index(_:offsetBy:)`
* Use equivalency language more places; sync across array types
* Use k instead of n for parameter names
* Slight changes to index(_:offsetBy:) discussion.
* Update tests with new parameter names
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
* [SR-4005] Allow heterogenous comparisons in elementsEqual
When a user is supplying a predicate to compare the type equivalence
isn’t required
* elementsEqualWithPredicate tests
Compares a string of a number with an integer value by using the
elementsEqualPredicate closure
* Update test expectations to use new sequence element types
* Update hardcoded test to reference sequence
When matching inputs of a function type, be sure to
strip off ParenType sugar so that we don't end up
with ParenTypes in associated type witnesses.
This fixes various issues with SE-0110.
Fixes <rdar://problem/32214649>.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
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.
This fixes several issues:
- By default parent types of alias types are not printed which results in
- Erroneous fixits, for example when casting to 'Notification.Name' from a string, which ends up adding erroneous cast
as "Name(rawValue: ...)"
- Hard to understand types in code-completion results and diagnostics
- When printing with 'fully-qualified' option typealias types are printed erroneously like this "<PARENT>.Type.<TYPEALIAS>"
The change make typealias printing same as nominal types and addresses the above.
- 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.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
