This is a new feature of Swift 5 mode, so it deserves at least a
little bit of explanation right in the diagnostic. If you have an
otherwise-fully-covered switch but can't assume the enum is frozen,
you'll now get this message:
switch covers known cases, but 'MusicGenre' may have additional
unknown values
Furthermore, if the enum comes from a system header, it looks like
this:
switch covers known cases, but 'NSMusicGenre' may have additional
unknown values, possibly added in future versions
...to further suggest the idea that even though your switch is covered
/now/, it might not handle everything in the /future/. This extra bit
is limited to system headers to avoid showing up on C enums defined in
your own project, for which it sounds silly. (The main message is
still valid though, since you can cram whatever you want into a C
enum, and people use this pattern to implement "private cases".)
rdar://problem/39367045
Avoid implicitely assuming 'null' node if its OpaqueSyntaxNode is null, there should be no interpretation
of OpaqueSyntaxNode values, a SyntaxParseActions implementation should be able to return null pointers as OpaqueSyntaxNode.
Doing a "direct ParsedSyntaxRecorder::record[some syntax]" call from the parser is not a good idea due to possibility
of being in a backtracking context when the call is made. Replace them with "ParsedSyntaxRecorder::make[some syntax]"
which will implicitly check for backtracking and create a recorded or deferred node accordingly.
Instead of creating syntax nodes directly, modify the parser to invoke an abstract interface 'SyntaxParseActions' while it is parsing the source code.
This decouples the act of parsing from the act of forming a syntax tree representation.
'SyntaxTreeCreator' is an implementation of SyntaxParseActions that handles the logic of creating a syntax tree.
To enforce the layering separation of parsing and syntax tree creation, a static library swiftSyntaxParse is introduced to compose the two.
This decoupling is important for introducing a syntax parser library for SwiftSyntax to directly access parsing.
Sometimes constraint solver fails without producing any diagnostics,
it could happen during different phases e.g. pre-check, constraint
generation, or even while attempting to apply solution. Such behavior
leads to crashes down the line in AST Verifier or SILGen which are
hard to diagnose.
Let's guard against that by tracking if solver produced any diagnostics
upon its failure and if no errors were or are scheduled to be produced,
let's produce a fallback fatal error pointing at affected expression.
Resolves: rdar://problem/38885760
This lets the SIL optimizer reason about types (e.g. if a type is loadable) in specific functions.
For example, a type might be loadable in a resilient function, but not in an inlinable function.
Create two new semantic names: `ExternalImport` and `ExternalExport`.
These are for symbols which are either imported from an external module
or exported for consumption by external modules.
Sinking this logic into the IRLinkage application means that we can
clean up the various sites that are handling the IRLinkage and/or
DLLStorage to apply IRLinkage semantically, making the code easier to
understand as well as avoiding the proliferation of the `useDLLStorage`
checks.
This fixes the Windows platform, where the aligned allocation path is
not malloc-compatible. It won't have any observable difference on
Darwin or Linux, aside from manually allocated memory on Linux now
being consistently 16-byte aligned (heap objects will still be 8-byte
aligned on Linux).
It is unfortunate that we can't guarantee Swift-allocated memory via
Unsafe*Pointer is malloc compatible on Windows. It would have been
nice for that to be a cross platform guarantee since it's normal to
allocate in C and deallocate in Swift or vice-versa. Now we have to
tell developers to always use _aligned_malloc/_aligned_free when
transitioning between Swift/C if they expect their code to work on
Windows.
Even though this fix isn't required today on Darwin/Linux, it makes
good sense to guarantee that the allocation/deallocation paths are
consistent.
This is done by specifying a constant that stdlib can use to round up
alignment, _swift_MinAllocationAlignment. The runtime asserts that
this constant is greater than MALLOC_ALIGN_MASK for all platforms.
This way, manually allocated buffers will always use the aligned
allocation path. If users specify an alignment less than m
round up so users don't need
to pass the same alignment to deallocate the buffer). This constant
does not need to be ABI.
Alternatives are:
1. Require users of Unsafe*Pointer to specify the same alignment
during deallocation. This is obviously madness.
2. Introduce new runtime entry points:
swift_alignedAlloc/swift_alignedDealloc, introduce corresponding
new builtins, and have Unsafe*Pointer always call those. This would
make the runtime API a little more obvious but would introduce
complexity in other areas of the compiler and it doesn't have any
other significant benefit. Less than 16-byte alignment of manually
allocated buffers on Linux is a non-goal.
When we encounter the demangle tree for a bound generic class type, look
through the "Type" node of the child tree before checking whether we
have an Objective-C class name. If we do have an Objective-C class name,
there is no way to preserve the generic arguments, so we ignore them and
return the (non-generic) class type.
Fixes rdar://problem/47028102.
Generalizes the ConcreteExistentialInfo abstraction so it can be used
both by the ExistentialSpecializer and SILCombine, allowing redundant
code in ExistentialSpecializer.cpp to be deleted.
Splits OpenedArchetypeInfo from ConcreteExistentialInfo. Adds a
ConcreteOpenedArchetypeInfo convenience wrapper around them both, for
use wherever we were originally using ConcreteExistentialInfo.
Splits getAddressOfStackInit into getStackInitInst, This is cleaner and
allows both the ExistentialSpecializer and SILCombine to handle more
interesting cases in the future, like unconditional_checked_cast.
Creates utilities, initializeSubstitutionMap, and
initializeConcreteTypeDef to simplify an generalize
ConcreteExistentialInfo.
While rewriting ExistentialSpecializer to use the new
abstraction, I fixed a latent bug in which is was using a SIL
argument index as a function type parameter index (this would
have broken up if/when we decide to enable calls with indirect
results).
Parsing collection literal expression used to take exponential time
depending on the nesting level of the first element.
Stop using 'parseList()' because using it complicates libSyntax parsing.
rdar://problem/45221238 / https://bugs.swift.org/browse/SR-9220
rdar://problem/38913395 / https://bugs.swift.org/browse/SR-7283
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.
