When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
When compiling the OnoneSupport library, the compiler checks for @_semantics("prespecialize.X") attributes to pre-specialize function X.
rdar://problem/48924409
This is a step in the direction of fixing the fallthrough bug. Specifically, in
this commit I give case stmts a set of var decls for the bodies of the case
statement. I have not wired them up to anything except the var decl
list/typechecking.
rdar://47467128
I also removed the -verify-sil-ownership flag in favor of a disable flag
-disable-sil-ownership-verifier. I used this on only two tests that still need
work to get them to pass with ownership, but whose problems are well understood,
small corner cases. I am going to fix them in follow on commits. I detail them
below:
1. SILOptimizer/definite_init_inout_super_init.swift. This is a test case where
DI is supposed to error. The only problem is that we crash before we error since
the code emitting by SILGen to trigger this error does not pass ownership
invariants. I have spoken with JoeG about this and he suggested that I fix this
earlier in the compiler. Since we do not run the ownership verifier without
asserts enabled, this should not affect compiler users. Given that it has
triggered DI errors previously I think it is safe to disable ownership here.
2. PrintAsObjC/extensions.swift. In this case, the signature generated by type
lowering for one of the thunks here uses an unsafe +0 return value instead of
doing an autorelease return. The ownership checker rightly flags this leak. This
is going to require either an AST level change or a change to TypeLowering. I
think it is safe to turn this off since it is such a corner case that it was
found by a test that has nothing to do with it.
rdar://43398898
* Teach the importer to import any vector type as SIMDN<Scalar>.
Instead of having a known set of vector types, check to see if the
element type conforms to SIMDScalar; if it does, see if we have a
SIMDN defined with the right number of elements. If both are satisfied,
import the vector type as that Swift type.
By making this change, we gain the ability to import vector types
that aren't defined in terms of the Darwin simd module, which lets
us use C API with vector types on other platforms. It also lets us
import *every* vector type that Swift can represent, rather than the
small subset that are currently hardcoded.
* Increased test coverage for increased SIMD types that we can import.
Includes some minor cleanup from review. Also eliminates the old
simd_sans_simd test, since we can now import all of these types even when the simd module isn't imported.
In addition to being wasteful, this is a correctness issue -- the
compiler should only ever have one view of this file, and it should not
read a potentially different file after validating dependencies.
rdar://48654608
(as described in the previous commit)
When printing an interface that has to be stable, we need to use the
module name that identifies where declarations should be searched for,
just like we do with serialization.
rdar://problem/49114811
It's a pretty obscure feature (and one we wish we didn't need), but
sometimes API is initially exposed through one module in order to
build another one, and we want the canonical presented name to be
something else. Push this concept into Swift's AST properly so that
other parts of the compiler stop having to know that this is a
Clang-specific special case.
No functionality change in this commit; will be used in the next
commit.
Before extending TupleShuffleExpr to represent all tuple
conversions allowed by the constraint solver, remove the
parts of TupleShuffleExpr that are no longer needed; this is
support for default arguments, varargs, and scalar-to-tuple and
tuple-to-scalar conversions.
Right now we use TupleShuffleExpr for two completely different things:
- Tuple conversions, where elements can be re-ordered and labels can be
introduced/eliminated
- Complex argument lists, involving default arguments or varargs
The first case does not allow default arguments or varargs, and the
second case does not allow re-ordering or introduction/elimination
of labels. Furthermore, the first case has a representation limitation
that prevents us from expressing tuple conversions that change the
type of tuple elements.
For all these reasons, it is better if we use two separate Expr kinds
for these purposes. For now, just make an identical copy of
TupleShuffleExpr and call it ArgumentShuffleExpr. In CSApply, use
ArgumentShuffleExpr when forming the arguments to a call, and keep
using TupleShuffleExpr for tuple conversions. Each usage of
TupleShuffleExpr has been audited to see if it should instead look at
ArgumentShuffleExpr.
In sequent commits I plan on redesigning TupleShuffleExpr to correctly
represent all tuple conversions without any unnecessary baggage.
Longer term, we actually want to change the representation of CallExpr
to directly store an argument list; then instead of a single child
expression that must be a ParenExpr, TupleExpr or ArgumentShuffleExpr,
all CallExprs will have a uniform representation and ArgumentShuffleExpr
will go away altogether. This should reduce memory usage and radically
simplify parts of SILGen.
* [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
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
This is in preparation for fixing issues around SILGenPattern fallthrough
emission and bad rename/edit all in scope of case stmt var decls. Specifically,
I am going to ensure that we can get from any VarDecl in the following to any
other VarDecl:
switch x {
case .a(let v1, let v2), .b(let v1, let v2):
...
fallthrough
case .c(let v1, let v2), .d(let v1, let v2):
...
}
This will be done by:
1. Pointing the var decls in .d at the corresponding var decls in .c.
2. Pointing the var decls in .c at the corresponding var decls in .b.
3. Pointing the var decls in .b at the corresponding var decls in .a.
4. Pointing the var decls in .a at the case stmt. Recognizing that we are asking
for the next VarDecl, but have a case stmt, we check if we have a fallthrough
case stmt. If so, follow down the fallthrough case stmts until you find a
fallthrough case stmt that doesn't fallthrough itself and then return the
corresponding var decl in the last case label item in that var decl (in the
above .d).
In a subsequent commit I am going to add case body var decls. The only change as
a result of that is that I will insert them into the VarDecl double linked list
after the last case var decl of each case stmt.
I did not wire anything up to it.
This is in preparation for fixing issues around SILGenPattern fallthrough
emission and bad rename/edit all in scope of case stmt var decls. Specifically,
I am going to ensure that we can get from any VarDecl in the following to any
other VarDecl:
switch x {
case .a(let v1, let v2), .b(let v1, let v2):
...
fallthrough
case .c(let v1, let v2), .d(let v1, let v2):
...
}
This will be done by:
1. Pointing the var decls in .d at the corresponding var decls in .c.
2. Pointing the var decls in .c at the corresponding var decls in .b.
3. Pointing the var decls in .b at the corresponding var decls in .a.
4. Pointing the var decls in .a at the case stmt. Recognizing that we are asking
for the next VarDecl, but have a case stmt, we check if we have a fallthrough
case stmt (which I am going to add in a subsequent commit). If so, follow down
the fallthrough case stmts until you find a fallthrough case stmt that doesn't
fallthrough itself and then return the corresponding var decl in the last case
label item in that var decl (in the above .d).
I also put in some asserts to make sure that we never try to vend a parent value
that is a nullptr.
rdar://47467128
Directly implement the data flow. Eliminate the extraneous work.
Remove cubic behavior. Do a single iteration of the data flow state at
each program point only performing the necessary set operations. At
unidentified access, clear the sets for simplicity and efficiency.
This cleanup results in significant functional changes:
- Allowing scopes to merge even if they are enclosed.
- Handling unidentified access conservatively.
Note that most of the added lines of code are comments.
Somehow this cleanup incidentally fixes:
<rdar://problem/48514339> swift compiler hangs building project
(I expected the subsequent loop summary cleanup to fix that problem.)
The previous design was customized to perfoming IPO with
GenericSideEffectAnalysis. Expose the underlying logic as a utility so
that AccessEnforcementOpts can use it to summarize loops (in addition
to call sites).
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
The observer in a dynamic replacement of variables with a observer will
provide the dynamic replacement for the original.
var original : Int = 0 {
didSet {
print("original")
}
}
@_dynamicReplacement(for: original)
var replacement : Int = 0 {
didSet {
print("replacement")
}
}
rdar://48518788
