The main fixes here are:
- we weren't looking through open-existentials in the l-value
- we weren't handling mutating gets correctly unless CSApply wrapped
the base in an InOutExpr, which seems to be multifile-sensitive
- we were missing diagnostics in some cases involving subscripts
A better fix would be to re-introduce LValueAccessKind, but I wanted
a workable short-term fix that I could try to get into 5.1.
Fixes rdar://49482742, which is specific to the lazy-getter problem.
First, if the base parameter is inout or vararg, the derived parameter
must be too. Second, we do not allow covariant overrides of inout or
vararg parameters.
Fixes <https://bugs.swift.org/browse/SR-10231>.
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
Unless -enable-resilient-objc-class-stubs is passed in, these cases
are not supported, so now we diagnose them instead of asserting or
failing to link.
Note the behavior change here; classes with resilient ancestry were
previously isObjC(). However this is wrong since isObjC() means
"statically visible to Objective-C via the generated header".
After this patch, isObjC() only returns true for a class with resilient
ancestry if -enable-resilient-objc-class-stubs is passed in.
* [typechecker] fix an issue with redeclaration checking
* [typechecker] use mapSignatureFunctionType in getOverloadSignatureType() to compute the type for the enum element decl, etc
* [typechecker] allow matching enums to functions as well, not just functions to enums
* [typechecker] fix the check for two enums
* [typechecker] check for nominal types as well when comparing enum elements
* [test] add more tests
* [typechecker] check for typealias as well
* 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
Decodable’s init(from:) synthesis sometimes mistook a static property for an identically-named instance property, which could cause it to skip a property or possibly make other mistakes. This change factors a common helper function from encode(to:) and init(from:) synthesis which implements the right logic for both.
* Revise error for incorrect subscript parameters.
We use subscripts for more than just indexes in Swift these days, so
the error message needs to be a bit more general.
* Use the term 'argument' instead of 'value'
For context, String, Nil, Bool, and Int already behave this way.
Note: Swift can compile against 80 or 64 bit floats as the builtin
literal type. Thus, it was necessary to capture this bit somehow in the
FloatLiteralExpr. This was done as another Type field capturing this
info.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
