Accessors logically belong to their storage and can be synthesized
on the fly, so removing them from the members list eliminates one
source of mutability (but doesn't eliminate it; there are also
witnesses for derived conformances, and implicit constructors).
Since a few ASTWalker implementations break in non-trivial ways when
the traversal is changed to visit accessors as children of the storage
rather than peers, I hacked up the ASTWalker to optionally preserve
the old traversal order for now. This is ugly and needs to be cleaned up,
but I want to avoid breaking _too_ much with this commit.
Introduce some template metaprogramming infrastructure to retrieve the
"nearest" source location to the inputs of a request, and use that to
provide default diagnoseCycle and noteCycleStep implementations. This
will help remove a bunch of boilerplate from new requests.
Computing the requirement signature created the generic params as
a side effect. Making getRequirementSignature lazy means that users
of the generic params must make sure they are created before use.
* Make Self available to instance member functions (SE-0068?)
* Works for value types and static functions.
* Further experiments with TypeExpr
* Move Self processing off diagnostic path
* diagnostic instead of assertion fail
* TypeExpr of DynamicSelfType now working.
* Update tests for availability of Self
* Cast to Self fixed!
* Self not available as type in classes except for return type
* Could it be this simple?
* Nearly there
* Fix function decls using Self inside methods.
* Fix validation-test/compiler_crashers_2_fixed/0164-sr7989.swift
* Fix of ./validation-test/compiler_crashers_2_fixed/0179-rdar44963974.swift
* "Un-fix" validation-test/compiler_crashers_2_fixed/0164-sr7989.swift
* CHANGELOG entry
* Update CHANGELOG.md
Co-Authored-By: johnno1962 <github@johnholdsworth.com>
* Update CHANGELOG.md
This is like '@inlinable', except that the symbol does not have a public
entry point in the generated binary at all; it is deserialized and a copy
is always emitted into the client binary, with shared linkage.
Just like '@inlinable', if you apply this to an internal declaration it
becomes '@usableFromInline' automatically.
This uses the same mechanism as default arguments ever since Swift 4, so
it should work reasonably well, but there are rough edges with diagnostics
and such. Don't use this if you are not the standard library.
Fixes <rdar://problem/33767512>, <https://bugs.swift.org/browse/SR-5646>.
The bulk of the changes are to SILGenApply. As we must now evaluate the
payload ArgumentSource to an RValue, we follow the example of subscripts
and lie to the argument emitter. This evaluates arguments at +1 which
can lead to slightly worse codegen at -Onone.
Otherwise we generate a call to String(reflecting:), which correctly handles many things we may not be able to (like private types), and which matches the default implementation of Error._domain.
GenericParamList::OuterParameters would mirror the nesting structure
of generic DeclContexts. This resulted in redundant code and caused
unnecessary complications for extensions and protocols, whose
GenericParamLists are constructed after parse time.
Instead, lets only use OuterParameters to link together the multiple
parameter lists of a single extension, or parameter lists in SIL
functions.
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Simple checks for the presence of a protocol in the “inherited” list should only
require a scan through that list + name lookup; use those facilities instead of
recursing through the type checker.
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
In Swift 3 mode, the canonical private DeclContext should
not look through extensions.
The only way I can reproduce this is with a missing warning
and we don't really care about missing warnings in Swift 3 mode.
However, the next patch in this PR regresses more things so
let's fix it properly.
If an extension refers to a generic typealias that has yet to resolve to
a fully-sugared type, look through the underlying type.
Fixes rdar://problem/39023438.
This function was unable to "look through" an unbound generic typealias to
find the underlying nominal type that was getting extended, which can occur
if we end up performing a name lookup into this context before the extension
itself has been fully-checked.
Also, test that extending DictionaryIndex works.
Adding getAsGenericContext() cleans up some code, and improves the
Swift.swiftmodule build time by almost half a percent on LLVM
top-of-tree and with a simulated fix for LLVM PR35909.
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
We want stored property initializers of fixed layout structs to be
inlinable, so that inlinable initializers can be fully eliminated
by the optimizer.
This is the first step in fixing <rdar://problem/36454839>.
