* Add experimental feature `PlaygroundExtendedCallbacks` which passes more information in `-playground` callbacks
Adds the experimental feature `PlaygroundExtendedCallbacks` which (when `-playground` is also passed) causes the playground transform to use alternate forms of the result-value, scope-entry, and scope-exit callbacks that include the module name and file path of the source file.
The previous callbacks included integers for the module number and file number, but this was cumbersome to use because it required the caller to create source symbols with magical names formed from the module name and file path that the playground transform knew how to look up.
The extended callbacks in the experimental feature instead pass these strings as string literals. This is an experimental feature because of the need to measure the performance impact, and because of the need to provide an option to control which set of callbacks to use so that existing clients of the playground transform can opt into it when ready. It's also likely that we'll want to pass more information in the extended callbacks, such as an indication of the kind of result is being logged (e.g. a loop iteration variable vs a return statement vs a variable assignment). So this should be considered the first of a series of experimental improvements that will then be pitched as an actual, non-experimental v2.0 of the playground transform callback API. Because of the nature of how the playground transform is used, it's much easier to iterate on the functionality in the form of an experimental feature rather than using only desktop debug builds of the Swift compiler.
Changes:
- define a new experimental feature called `PlaygroundExtendedCallbacks`
- modify the playground transform step in sema to pass the module name and file name literals when the experimental feature is set
- add a unit test for the extended callbacks
There is no change in behaviour when `PlaygroundExtendedCallbacks` is not enabled.
rdar://109911742
Co-authored-by: Brent Shank <bshank@apple.com>
LLVM deprecated, renamed, and removed a bunch of APIs. This patch
contains a lot of the changes needed to deal with that.
The SetVector type changed the template parameters.
APInt updated multiple names, countPopulation became popcount,
getAllOnesValue became getAllOnes, getNullValue became getZero, etc...
Clang type nullability check stopped taking a clang AST context.
The LLVM IRGen Function type stopped exposing basic block list directly,
but gained enough API surface that the translation isn't too bad.
(GenControl.cpp, LLVMMergeFunctions.cpp)
llvm::Optional had a transform function. That was being used in a couple
of places, so I've added a new implementation under STLExtras that
transforms valid optionals, otherwise it returns nullopt.
LLVM removed findFirstSet and findLastSet functions from MathExtras and
doesn't have a direct replacement. We only have once instance of these
functions used in the compiler, so I've replaced them inline with the
appropriate bit operations.
This patch migrates the compiler off of the deprecated LLVM APIs where I
can.
- APInt::getAllOnesValue -> APInt::getAllOnes
- APInt::getNullValue -> APInt::getZero
- APInt::isNullValue -> APInt::isZero
- APInt::getMinSignedBits -> APInt::getSignificantBits
- clang::Module::submodule_{begin,end} -> clang::Module::submodules
Upcoming and experimental features are supported via command-line flags
and also in the SwiftPM manifest. Introduce it as an experimental
feature so that it can be enabled via SwiftPM without having to resort
to unsafe flags.
The `StrictConcurrency` experimental feature can also provide a
strictness level in the same manner as `-strict-concurrency`, e.g.,
`StrictConcurrency=targeted`. If the level is not provided, it'll be
`complete`.
Note that we do not introduce this as an "upcoming" feature, because
upcoming features should be in their final "Swift 6" form before
becoming available. We are still tuning the checking for concurrency.
The reason why I am doing this is that this was not part of the original
evolution proposal (it was called an extension) and after some discussion it was
realized that partial consumption would benefit from discussion on the forums.
rdar://111353459
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
One can still in resilient frameworks have noncopyable frozen types.
This means that one cannot make a noncopyable:
1. Full resilient public type.
2. @usableFromInline type.
NOTE: One can still use a frozen noncopyable type as a usableFromInline class
field. I validated in the attached tests that we get the correct code
generation.
I also eliminated a small bug in TypeCheckDeclPrimary where we weren't using a
requestified attr check and instead were checking directly.
rdar://111125845
Its storage vector is intended to be of some type like
`std::vector<std::pair<Key, Optional<Value>>>`, i.e., some collection of
pairs whose `second` is an `Optional<Value>`. So when constructing a
default instance of that pair, just construct an Optional in the None
case.
`lib/swift/host` contains modules/libraries that are built by the host
compiler. Their `.swiftmodule` will never be able to be read, ignore
them entirely.
Teach swift dependency scanner to use CAS to capture the full dependencies for a build and construct build commands with immutable inputs from CAS.
This allows swift compilation caching using CAS.
Lazy member loading has been in use and the default for several years
now. However, the lazy loading was disabled for any type whose primary
definition was parsed even though some of its extensions could have
been deserialized, e.g., from a Clang module. Moreover, the non-lazy
path walked all of the extensions of such a type for all member name
lookup operations. Faced with a large number of extensions to the same
type (in my example, 6,000), this walk of the list of the extensions
could dominate type-checking time.
Eliminate all effects of the `-disable-named-lazy-member-loading`
flag, and always use the "lazy" path, which effectively does no work
for parsed type definitions and extensions thereof. The example with
6,000 extensions of a single type goes from type checking in 6 seconds
down to type checking in 0.6 seconds, and name lookup completely
disappears from the profiling trace.
The deleted tests relied on the flag that is now inert. They aren't by
themselves providing much value nowadays, and it's better to have the
simpler (and more efficient) implementation of member name lookup be
the only one.
Intro a deserialization mode controlled by the flag
`-experimental-force-workaround-broken-modules` to attempt unsafe
recovery from deserialization failures caused by project issues.
The one issue handled at this time is when a type moves from one module
to another. With this new mode the compiler may be able to pick a
matching type in a different module. This is risky to use, but may help
in a pinch for a client to fix and issue in a library over which they
have no control.
* Add @_used and @_section attributes for global variables and top-level functions
This adds:
- @_used attribute that flags as a global variable or a top-level function as
"do not dead-strip" via llvm.used, roughly the equivalent of
__attribute__((used)) in C/C++.
- @_section("...") attribute that places a global variable or a top-level
function into a section with that name, roughly the equivalent of
__attribute__((section("..."))) in C/C++.
Deserialization recovery silently drops errors and the affected decls.
This can lead to surprises when a function from an imported module
simply disappears without an explanation.
This commit introduces the flag -Rmodule-recovery to report as remarks
some of these previously silently dropped issues. It can be used to
debug project configuration issues.
* [ModuleInterface] Add mechanism to exclude experimental flags from the module interface
rdar://109722548
* Separate filtered flags from the typical/unfiltered case
Introduce a new experimental feature `ASTGenTypes` that uses ASTGen to
translate the Swift syntax tree (produced by the new Swift parser)
into C++ `TypeRepr` nodes instead of having the C++ parser create the
nodes.
The approach here is to intercept the C++ parser's `parseType`
operation to find the Swift syntax node at the given position (where
the lexer currently is) and have ASTGen translate that into the
corresponding C++ AST node. Then, we spin the lexer forward to the
token immediately following the end of the syntax node and continue
parsing.
We may want to revisit this in the future, but for
now let's avoid profiling code in generated
buffers. To make this work we'll need to come up
with a scheme for writing out the generated buffers
such that tools like `llvm-cov` can reference them.
rdar://109562235
This will mean that '-disable-implicit-swift-modules' also automatically implies two things:
1. Clang modules must also be explicit, and the importer's clang instance will get '-fno-implicit-modules' and '-fno-implicit-module-maps'
2. The importer's clang instance will no longer get a '-fmodules-cache-path=', since it is not needed in explicit builds
The new LexicalLifetimes suppressible language feature results in
declarations annotated with @_eagerMove, @_noEagerMove, and
@_lexicalLifetimes to be printed with that attribute when it's available
and without it when it's not.
