This matches the behavior of `printAlwaysOnStatsAndTimers`,
which we use in a release build. This fixes the
diverging behavior, and ensures process-stats-dir
can handle comparing deltas between runs where
one of the runs had a 0 counter.
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
Teach swift how to serialize its input into CAS to create a cache key
for compiler outputs. To compute the cache key for the output, it first
needs to compute a base-key for the compiler invocation. The base key is
computed from: swift compiler version and the command-line arguments for
the invocation.
Each compiler output from swift will gets its own key. The key for the
output is computed from: the base key for the compiler invocation + the
primary input for the output + the output type.
C stdlib headers are part of "Darwin"/"Glibc" clang module.
If a Swift file imports a bridging headers and that has '#include'
C stdlib headers, Swift compiler implicitly imports "Darwin"/"Glibc"
overlay modules. That violates dependency layering. I.e. Compiler
depends on Darwin overlay, Darwin overlay is created by the compiler.
rdar://107957117
Add a helper to allow us to programatically extract the Swift version
string during the build. This is particularly useful for injection into
the packaging stages.
Co-authored-by: Evan Wilde <etceterawilde@gmail.com>
This allows building the Swift standard library for targets which may
not have an actual OS running. This is identified by the OS field in
the target triple being set to `none`.
Executable compiler plugins are programs invoked by the host compiler
and communicate with the host with IPC via standard IO (stdin/stdout.)
Each message is serialized in JSON, prefixed with a header which is a
64bit little-endian integer indicating the size of the message.
* Basic/ExecuteWithPipe: External program invocation. Lik
llvm::sys::ExecuteNoWait() but establishing pipes to the child's
stdin/stdout
* Basic/Sandbox: Sandboxed execution helper. Create command line
arguments to be executed in sandbox environment (similar to SwiftPM's
pluging sandbox)
* AST/PluginRepository: ASTContext independent plugin manager
* ASTGen/PluginHost: Communication with the plugin. Messages are
serialized by ASTGen/LLVMJSON
rdar://101508815
Macro expansion buffers, along with other generated source buffers,
need more precise "original source ranges" that can be had with the
token-based `SourceRange`. Switch over to `CharSourceRange` and provide
more thoughtfully-determined original source ranges.
The main problem that prevented us from reusing the ASTContext was that we weren’t remapping the `LocToResolve` in the temporary buffer that only contains the re-parsed function back to the original buffer. Thus `NodeFinder` couldn’t find the node that we want to get cursor info for.
Getting AST reuse to work for top-level items is harder because it currently heavily relies on the `HasCodeCompletion` state being set on the parser result. I’ll try that in a follow-up PR.
rdar://103251263
Use the std-equivalent names as the LLVM ones are now deprecated
(eventually `llvm::Optional` will disappear):
- `getValue` -> `value`
- `getValueOr` -> `value_or`
- `hasValue` -> `has_value`
Follow up from ab1b343dad and
7d8bf37e5e with some missing cases.
When emitting a diagnostic that references a declaration that does not
itself have a source location (e.g., because it was synthesized or
deserialized), the diagnostics engine pretty-prints the declaration
into a buffer so it can provide caret diagnostics pointing to that
declaration.
Start marking those buffers as "generated source buffers", so that we
emit their contents into serialized diagnostics files. This will allow
tools that make use of serialized diagnostics to also show caret
information.
When a declaration has a structural opaque return type like:
func foo() -> Bar<some P>
then to mangle that return type `Bar<some P>`, we have to mangle the `some P`
part by referencing its defining declaration `foo()`, which in turn includes
its return type `Bar<some P>` again (this time using a special mangling for
`some P` that prevents infinite recursion). Since we mangle `Bar<some P>`
once as part of mangling the declaration, and we register substitutions for
bound generic types when they're complete, we end up registering the
substitution for `Bar<some P>` twice, once as the return type of the
declaration name, and again as the actual type. This would be fine, except
that the mangler doesn't check for key collisions, and it picks
substitution indexes based on the number of entries in its hash map, so
the duplicated substitution ends up corrupting the substitution sequence,
causing the mangler to produce an invalid mangled name.
Fixing that exposes us to another problem in the remangler: the AST
mangler keys substitutions by type identity, but the remangler
uses the value of the demangled nodes to recognize substitutions.
The mangling for `Bar<current declaration's opaque return type>` can
appear multiple times in a demangled tree, but referring to different
declarations' opaque return types, and the remangler would reconstruct
an incorrect mangled name when this happens. To avoid this, change the
way the demangler represents `OpaqueReturnType` nodes so that they
contain a backreference to the declaration they represent, so that
substitutions involving different declarations' opaque return types
don't get confused.
Establish the relationship for generated sources, whether for macro
expansions or (via a small stretch) replacing function bodies with
other bodies, in the source manager itself. This makes the information
available for diagnostic rendering, and unifies a little bit of the
representation, although it isn't used for much yet.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Ensure that any time the existing parser accepts a source file,
the new parser produces a valid parse (no unexpected/missing nodes) for
that same source file.
