This type is intended to be used to wrap compiler synthesized nodes
(i.e. variables) to make it easier for diagnostic to diagnose precise
failure locations.
Consider the situation like:
```
protocol P {}
extension Array: P where Element: P {}
func test<T: P>() -> T {
$_a = ...
$_b = ...
return [$_a, $_b]
}
```
This is a common pattern with result builders.
In this case if one of the elements don't conform to `P` the best
user experience would be to attach diagnostic to the element otherwise
the developers would have to figure out where in result expression
the error occured before attempting to fix it.
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
Make the pointer to uniqued storage an implementation detail of an
`AvailabilityContext` value. This way clients of `AvailabilityContext` don't
need to think about pointers and can have access to mutating operations on a
context when appropriate.
This class is designed to be a compact representation of the active
availability constraints in a specific scope. For now, it only models platform
introduction availability but it will soon be updated to cover additional
availability constraints, like platform unavailability.
In anticipation of needing to reference `AvailabilityContext`s from
`TypeRefinementContext`s and increasing memory requirements for these contexts,
a cache of uniqued instances of `AvailabilityContext` are stored in a
`llvm::FoldingSet` on `ASTContext`.
This adds a pair of Swift protocols that represents C++ iterator types conforming to `std::contiguous_iterator_tag` requirements. These are random access iterators that guarantee that the values are stored in consequent memory addresses.
This will be used to optimize usage of C++ containers such as `std::vector` from Swift, for instance, by providing an overload of `withContiguousStorageIfAvailable` for contiguous containers.
rdar://137877849
The availability macros definitions are parsed from the command line and
stored in a cache. The cache was in the Parser, which would have it be
computed for each file using availability macros. Let's move it to the
ASTContext instead where it can generally be computed once per invocation
and used across the module.
rdar://134797088
Make sure block-list file is read through VFS so CASFS can be used to
read the configuration to ensure sound caching, and also the path of the
blocklist can be canonicalized via path remapping.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
When looking up the decl context of a type, ASTDemangler has to take
into account that there are multiple different modules where that type
could've come from. This is due to two facts:
- Thanks to the `-module-abi-name` flag, multiple modules can share
the same ABI name (which is the module name that is usually used when
mangling a type).
- In some situations mangling can use the module's real name, for
example, when mangling for the debugger or USRs coupled with @_originallyDefinedIn.
rdar://134095412
This conforms mutable C++ container types, such as `std::vector`, to `MutableCollection` via a new overlay protocol `CxxMutableRandomAccessCollection`.
rdar://134531554
Fix a bug that swift clang importer is not setup correctly when prefix
map is used. There are two separate issues:
* CC1 args used to setup clang import when building swift (interface and
sources) are not correctly remapped.
* When loading SDKInfo from SDK path, the SDKSettings.json is not
loading from VFS, thus the file cannot be loaded from remapped path.
rdar://134458611
When referencing a declaration, check whether any of the types in that
reference are unsafe. This can diagnose cases where the original
declaration either wasn't actually unsafe, or is being provided with
unsafe types via generics.
Unlike all of the other build configuration checks, `canImport` has
side effects including the emission of various diagnostics. Thread a
source location through here so the diagnostics end up on the right
line.
In the accepted proposal for SE-0421, `next(_:)` became `next(isolation:)`.
Some of the references to that method in the codebase need to be updated
accordingly.
