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.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Re-applied after fixing a bug in Serialization where the DeclContext
wasn't being set correctly for extensions with nested parameters. I
was unable to come up with a reduced test case, but the CoreStore
project in the source compatibility suite was failing without the
Serialization change, and now it isn't.
If the sub-expression of the 'try?' is optional, the result will be the same level of optional-ness.
If the sub-expression is non-optional, the result is optional.
Thus, the following lines all end up with the same type of 'Int?'
- let x = try? 3 as Int
- let x = try? 3 as? Int
- let x = try? 3 as Int?
`array-to-pointer` and other conversions are not restricted to apply
expressions, (dynamic) subscript arguments have them too, which
verifier has to support.
Resolves: rdar://problem/45825806
The `Stmt` and `Expr` classes had both `dump` and `print` methods that behaved similarly, making it unclear what each method was for. Following a conversation in https://forums.swift.org/t/unifying-printing-logic-in-astdumper/15995/6 the `dump` methods will be used to print the S-Expression-like ASTs, and the `print` methods will be used to print the more textual ASTPrinter-based representations. The `Stmt` and `Expr` classes seem to be where this distinction was more ambiguous. These changes should fix that ambiguity.
A few other classes also have `print` methods used to print straightforward representations that are neither the S-Expressions nor ASTPrinters. These were left as they are, as they don't cause the same ambiguity.
It should be noted that the ASTPrinter implementations themselves haven't yet been finished and aren't a part of these changes.
* Introduce stored inlinable function bodies
* Remove serialization changes
* [InterfaceGen] Print inlinable function bodies
* Clean up a little bit and add test
* Undo changes to InlinableText
* Add serialization and deserialization for inlinable body text
* Allow parser to parse accessor bodies in interfaces
* Fix some tests
* Fix remaining tests
* Add tests for usableFromInline decls
* Add comments
* Clean up function body printing throughout
* Add tests for subscripts
* Remove comment about subscript inlinable text
* Address some comments
* Handle lack of @objc on Linux
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
Change a couple of getAs() to castTo(), so that we assert instead of
crashing with a null pointer dereference if a TupleShuffleExpr has
the wrong type.
Note that the verifier can no longer assert that validated
declarations have access, because... they don't! And there's
no separate verification level for finalized declarations,
so I'm just going to remove that check.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
Parsed declarations would create an untyped 'self' parameter;
synthesized, imported and deserialized declarations would get a
typed one.
In reality the type, if any, depends completely on the properties
of the function in question, so we can just lazily create the
'self' parameter when needed.
If the function already has a type, we give it a type right there;
otherwise, we check if a 'self' was already created when we
compute a function's type and set the type of 'self' then.
- 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.
The property that we are checking for here isn’t really local to the
nominal type or extension declaration, and triggers semantic queries
that aren’t needed elsewhere. Remove it, because it’s not adding value.
The verifier asserts that declarations whose interface type contains an error
are invalid, so let's just mark them invalid when we set the interface type,
instead of needlessly duplicating this logic all over the declaration checker.
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
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().
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
The existing verification seems unnecessarily brittle, but this isn't
a general fix for that problem. This fixes one instance of where we
are generating perfectly valid pointer conversions that the verifier
is currently blowing up on.
I've opened https://bugs.swift.org/browse/SR-8264 to track reworking
this verification to not be quite so brittle.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
