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
To determine the correct enum layout, we first count various
categories of cases. Before, we counted indirect generic cases as
"generic", but regular "generic" cases can't export spare bits.
Change this to count "indirect" cases as a separate category.
In particular, this ensures that fully-indirect enums use
spare bits from the pointers even when some or all of the cases
are generic.
Resolves rdar://133890406
The first word in a class existential is the class pointer itself.
This pointer exposes spare bits differently depending
on the platform, which becomes apparent when you try to reflect
an Optional carrying such an MPE.
Add new test cases and some logic to zero out the first
word of spare bit information only on platforms with 8-byte pointers.
Such destroys mark the lifetime end of their operands along their
availability boundary. They are currently inserted in this test case
by the ClosureLifetimeFixup pass, but in the fullness of time they will
be present for every value which is not explicitly destroyed (that's
what complete OSSA lifetimes is mostly about).
Currently, such destroys are diagnosed by DiagnoseUnreachable. Fix the
diagnostic pass not to diagnose these valid instructions.
rdar://137960229
Class existentials expose spare bits from all of the pointers, not just the first one.
Due to a bad bug here, we were properly exposing spare bits from the first pointer,
but then claiming that all bits of subsequent pointers were spare.
This accidentally resulted in the correct operation on 64-bit targets
(it picked the highest-order spare bit, which happened to be spare
in both the broken mask and the correct mask). But on 32-bit targets,
this exposed the high-order bits of pointers, which is incorrect.
Expand the test a bit while we're here as well.
Resolves rdar://132715829
