Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
Previously, requests would fail silently by returning an empty struct
in the response.
With this change, responses will properly report fail with the internal
error.
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
For now, this means USRs of ParamDecls. Soon, default argument generators
for subscripts will need this too.
Fixes <https://bugs.swift.org/browse/SR-8660>, <rdar://problem/44435221>.
When CursorInfo finds a reference to a VarDecl that's implicit but has a parent
VarDecl (according to VarDecl::getParentVarDecl), act as if we found the parent
instead.
When printing its annotated decl, we would would assume the param's default
value is present if the default value kind was "Normal". The type checker
explicitly sets the default value to nullptr if it doesn't type check though, so
we were crashing for that case. Added the check.
Resolves rdar://problem/46694149
The right way is findBufferContainingLoc. getBufferIdentifierForLoc is
both slower and wrong in the presence of #sourceLocation.
I couldn't come up with a test for the change in IDE/Utils.cpp because
refactoring still seems to be broken around #sourceLocation. I'll file
bugs for that.
This allows us to dump it in the generated interface, though it's
still not syntax-highlighted. This is necessary for textual module
interfaces, but it's also just a longstanding request for Xcode's
"Generated Interface" / "Jump to Definition" feature.
rdar://problem/18675831
If walking into body of defer statement returns nullptr, it indicates
*cutting-off* walking. Previously there was wrong assertion where it
must be unmodified, non-nullptr return.
rdar://problem/41100570
'dynamic' is inherited and only applies to '@objc' entities.
The SourceKit test change is because we've changed our behavior
slightly: we won't infer @objc from an override unless the override is
correctly marked with 'override'. This is part of breaking up
dependencies, and should have little effect outside of tests.
More specifically, generic `typealias` type.
For instance:
typealias Pair<T, T> = (T, T)
typealias PairAlias = Pair
Interface type of `PairAlias` is `Pair.Type`, not `(T, T).Type`
Fixes crash in sourcekit cursorinfo.
rdar://problem/34348776
SourceKit doesn't use them and if any unrecognised LLVM options are
passed to llvm::cl::ParseCommandLineOptions() it calls exit(), bringing
down SourceKit.
Also use fprintf instead of llvm::errs() in Logging.cpp as it uses a
global C++ object that had already been destructed when logging the
above failure.
Resolves rdar://problem/38314383
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.
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
For example:
class Foo<T> {
let test: Bool = false
let items: [Int] = []
func foo() {
if test {} // crashes on test
for i in items {} // crashes on items
}
}
We were picking up the incorrect containing type (Bool rather than Foo<T>).
Resolves rdar://problem/36871908.
* [stdlib] Remove MutableCollection.sorted methods
This removes the implementations of sorted() and sorted(by:) on Mutable-
Collection, which only changed some minor wording in the docs.
This also adds documentation to the partition(by:) implementations so that
they will appear downstream.
* [stdlib] De-gyb CollectionAlgorithms.swift
* Update tests for MutableCollection.sorted() changes
