Darwin defines memcmp with optional pointers. Update SwiftShims to
define it to the same type to avoid deserialization failures where we
get one over the other and the types don't match anymore.
rdar://140596571
As the utility runs, new gens may become local: as access scopes are
determined to contain deinit barriers, their `end_access` instructions
become kills; if such an `end_access` occurs in the same block above an
initially-non-local gen, that gen is now local.
Previously, it was asserted that initially-non-local gens would not
encounter when visiting the block backwards from that gen. Iteration
would also _stop_ at the discovered kill, if any. As described above,
the assertion was incorrect.
Stopping at the discovered kill was also incorrect. It's necessary to
continue walking the block after finding such a new kill because the
book-keeping the utility does for which access scopes contain barriers.
Concretely, there are two cases:
(1) It may contain another `end_access` and above it a deinit barrier
which must result in that second scope becoming a deinit barrier.
(2) Some of its predecessors may be in the region, all the access scopes
which are open at the begin of this block must be unioned into the set
of scopes open at each predecessors' end, and more such access scopes
may be discovered above the just-visited `end_access`.
Here, both the assertion failure and the early bailout are fixed by
walking from the indicated initially-non-local gen backwards over the
entire block, regardless of whether a kill was encountered. If a kill
is encountered, it is asserted that the kill is an `end_access` to
account for the case described above.
rdar://139840307
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
Situations like:
```
let _: Double = <<CGFloat>>
<var/property of type Double> = <<CGFloat>>
```
Used to be supported due to an incorrect fix added in
diagnostic mode. Lower impact here means that right-hand
side of the assignment is allowed to maintain CGFloat
until the very end which minimizes the number of conversions
used and keeps literals as Double when possible.
Resolves: rdar://139675914
The _StringProcessing module provides a generic, collection-based
`contains` method that performs poorly for ranges and closed ranges.
This addresses the primary issue by providing concrete overloads
for Range and ClosedRange which match the expected performance for
these operations.
This change also fixes an issue with the existing range overlap tests.
The generated `(Closed)Range.overlap` tests are ignoring the "other"
range type when generating ranges for testing, so all overlap tests
are only being run against ranges of the same type. This fixes things
so that heterogeneous testing is included.
Add @PointerBounds macro
@PointerBounds is a macro intended to be applied by ClangImporter when
importing functions with pointer parameters from C headers. By
leveraging C attributes we can get insight into bounds, esapability, and
(eventually) lifetimes of pointers, allowing us to map them to safe(r)
and more ergonomic types than UnsafePointer.
This initial macro implementation supports CountedBy and Sizedby, but
not yet EndedBy. It can generate function overloads with and without an
explicit count parameter, as well as with UnsafeBufferPointer or Span
(if marked nonescaping), and any of their combinations. It supports
nullable/optional pointers, and both mutable and immutable pointers.
It supports arbitrary count expressions. These are passed to the macro
as a string literal since any parameters referred to in the count
expression will not have been declared yet when parsing the macro.
It does not support indirect pointers or inout parameters. It supports
functions with return values, but returned pointers can not be bounds
checked yet.
Bounds checked pointers must be of type Unsafe[Mutable]Pointer[?]<T>
or Unsafe[Mutable]RawPointer[?]. Count expressions must conform to
the BinaryInteger protocol, and have an initializer with signature
"init(exactly: Int) -> T?" (or be of type Int).
rdar://137628612
---------
Co-authored-by: Doug Gregor <dgregor@apple.com>
When we replay a solution, we must record changes in the trail, so fix the
logic to do that. This fixes the first assertion failure with this test case.
The test case also exposed a second issue. We synthesize a CustomAttr in
applySolutionToClosurePropertyWrappers() with a type returned by simplifyType().
Eventually, CustomAttrNominalRequest::evaluate() looks at this type, and passes
it to directReferencesForType(). Unfortunately, this entry point does not
understand type aliases whose underlying type is a type parameter.
However, directReferencesForType() is the wrong thing to use here, and we
can just call getAnyNominal() instead.
Fixes rdar://139237781.
`filterDisjunction` should ignore the choices that are already
disabled while attempting to optimize disjunctions related to
dynamic member lookup.
Resolves: rdar://139314763
This is a tool specifically designed to generate
Xcode projects for the Swift repo (as well as a
couple of adjacent repos such as LLVM and Clang).
It aims to provide a much more user-friendly experience
than the CMake Xcode generation (`build-script --xcode`).
Some statements introduce implicit braces and other things,
`walkExplicitReturnStmts` cannot ignore that while trying
to find explicit returns.
Resolves: rdar://139235128
The logic here for completion wasn't actually
helping things since it would result in adding the
var overload to the system, which would result
in an ErrorType binding. We could turn the ErrorType
into a placeholder when resolving the overload,
but the simpler solution is to just allow CSGen
to turn the reference into a PlaceholderType. This
matches what we do for regular solving, and fixes
a crash with an IUO completion.
rdar://89369091
This test forces the usage of macosx-x86_64 and will fail if the x86_64
slice of the stdlib has not been built. Mark it as only running on
macosx-x86_64 to avoid the test failure in that case.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Take the `Features.def` file used in other parts of the code and create
a file that can be used from the LLVM Lit configuration files to add new
available features that can be checked from the tests with `REQUIRES`
and others.
The file `lit.swift-features.cfg.inc` is preprocessed by Clang and
generates a file with Python syntax that can be loaded from both
`lit.site.cfg.in` files. The preprocessing output is copied into the
different test directories in the build directory, and added it is added
as a dependency of them, so it will be generate when the test run or
when `Features.def` changes.
`EXPERIMENTAL_FEATURES` are only enabled if they are available in
production or the compiler is being built with assertions, while
`UPCOMING_FEATURES` and the rest of the `LANGUAGE_FEATURES` are always
available.
When doing an unified build (Swift being an external project of LLVM),
the Swift build is at `<llvm build dir>/tools/swift`, and that is the
value of `swift_obj_root`. However many products are actually placed in
`<llvm build dir>`, like `bin/`, `include/` and things like
`lib/swift/...` and others.
A couple of macros tests check the error messages printed by the
compiler against `swift_obj_root` (by the replacement done in
`PathSanitizingFileCheck` of `BUILD_DIR`) when it should have been
checking them against the top-level build directory, which will work in
both unified and non-unified builds (like `build-script` builds).
This predicate is meant to ask if the loweredType is equal to
`getLoweredType(pattern, formalType)` for *some* abstraction pattern.
If the formal type contained an opaque archetype, we performed a
different check, because we asked if loweredEqual is equal to
`getLoweredType(AbstractionPattern(formalType), formalType)`.
This caused a spurious SIL verifier failure when the payload of an
existential contained an opaque archetype, because we lower the
payload with the most general AbstractionPattern, so that
@thin metatypes become @thick, etc.
The regression test exercises this bug, and also another bug that was
present in 6.0 but was already fixed on main by one of my earlier
refactorings.
Fixes rdar://problem/138655637.
On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`
To fix this, we also need to check if a module’s real path is inside the SDK.
Fixesswiftlang/sourcekit-lsp#1770
rdar://138210224
