The behavior of std::minmax with rvalue arguments is undefined after the
end of the expression that contains the call to minmax. This code to
special-case the comparisons for ARM vs. Thumb and macOS vs. Darwin was a
little overly clever anyway. Rewrite it to use straightforward comparisons.
This fixes a test failure in Serialization/target-incompatible.swift when
building with a recent version of clang, because these checks were completely
optimized away due to the undefined behavior. rdar://problem/28700005
This would have allowed us to triage rdar://problem/28305755 much
sooner. The actual problem is pretty bad: if you have too many methods
with the same selector, serialization just falls over. "Too many" is
in the thousands, which seems unlikely, but 'dealloc' can actually get
there if there are a lot of little classes, and 'init' might as well,
so we really should do better here.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
My earlier patch started serializing SIL basic blocks using the RPOT order. While it works, changing the existing order of BBs during the serialization may be very surprising for users. After all, serialization is not supposed to transform the code.
Therefore, this patch follows a different approach. It uses the existing order of BBs during the serialization. When it deserializes/parses SIL and detects a use of an opened archetype before its definition, it basically introduced a forward definition of this opened archetype. Later on, when the actual definition of the opened archetype is found, it replaces the forward definition. There is a correctness check at the end of a SIL function deserialization, which verifies that there are no forward definitions of opened archetypes left unresolved.
...with a better message than the generic "older version of the
compiler" one, when we know it's actually a different version of
Swift proper.
This still uses the same internal module version numbers to check
if the module is compatible; the presentation of language versions
is a diagnostic thing only.
Speaking of module version numbers, this deliberately does NOT
increment VERSION_MINOR; it's implemented in a backwards-compatible
way.
This will only work going forwards, of course; all existing modules
don't have a short version string, and I don't feel comfortable
assuming all older modules we might encounter are "Swift 2.2".
rdar://problem/25680392
We want to distinguish the special case of a library built with
-sil-serialize-all, from a SIL function that is [fragile] because
of an explicitly @_transparent or @inline(__always).
For now, NFC.
We did not serialize them because getting USR for extensions is tricky (USRs are
usually for value decls). This commit starts to make up an USR for an extension by combining
the extended nominal's USR with the USR of the first value member of the extension. We use
this made-up USR to associate doc comments when (de)serializing them.
The two types are nearly identical, and Fixnum is only in the Swift branches of LLVM,
not in mainline LLVM.
I do want to add ++ to PointerEmbeddedInt and fix some of this ugliness, but that'll
have to go through LLVM review, so it might take a bit.
Use the isScoped() bit to distinguish scoped imports from submodule
imports (both of which are split by null bytes in the string) so that we
don't try to lookup a submodule name as if it were a decl (leading to
assertion failures when it wasn't found).
This fixes interface generation of swift modules that import clang
submodules.
rdar://problem/24534122
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
Since resilience is a property of the module being compiled,
not decls being accessed, we need to record which types are
resilient as part of the module.
Previously we would only ever look at the @_fixed_layout
attribute on a type. If the flag was not specified, Sema
would slap this attribute on every type that gets validated.
This is wasteful for non-resilient builds, because there
all types get the attribute. It was also apparently wrong,
and I don't fully understand when Sema decides to validate
which decls.
It is much cleaner conceptually to just serialize this flag
with the module, and check for its presence if the
attribute was not found on a type.
That's how everything behaved anyway. Might as well make it explicit and
stop special-casing it.
I've left in compatibility for modules built with older compilers so that
people using the OS toolchains aren't immediately unable to debug their apps.
As soon as we change the module format in a more significant way, I can take
this out.
Groundwork for rdar://problem/21254367; see next commit.
Swift SVN r29437
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Now that we can pick up search paths from frameworks (necessary to debug
them properly), we can end up with exponential explosions leading to the
same search path coming up thousands of times, which destroys compilation
time /and/ debugger responsiveness. This is already hitting people with
frameworks compiled for app extensions (due to a mistaken approximation
of whether or not something is a framework), but we're turning this on for
all frameworks in the immediate future.
rdar://problem/20291720
Swift SVN r27087
In particular, this is problematic when libraries are loaded dynamically, and
may have newer deployment targets than the main executable.
Swift SVN r26786
Primarily, unique normal protocol conformances and reference them via
a conformance ID. This eliminates the use of trailing records for
normal protocol conformances and (more importantly) the cases were we
would write incomplete conformances. The latter could cause problems
if we ever ended up deserializing an incomplete conformance without
also deserializing a complete record for that same conformance.
Secondarily, simplify the way we write conformances. They are now
always trailing records, and we separate out the derived conformance
kinds (specialized/inherited) from either a reference to a normal
conformance in the current module file (via a normal conformance ID)
or via a cross-reference to a conformance in another module file
(currently always a normal conformance, but this need not always be
the case). As part of this, make each conformance record
self-sustaining, so we don't have to push information down to the
reading routines (e.g., the conforming type) to actually produce a
proper conformance. This simplifies deserialization logic further.
Swift SVN r26482
