It's like LLVM's MergeFunctions pass, except that it can also merge functions which differ by some constants.
The intention is to merge specialized functions which only differ by metadata lookups. But it can also merge other types of functions.
It gives ~7% code size reducation for the stdlib.
There are still some open TODOs, e.g. to share common code with LLVM's MergeFunctions pass (currently much code is just copied).
`ThreadSafeRefCntPtr.h` references `std::enable_if` and `std::move`,
but does not include `<type_traits>` or `<utility>`. This results
errors when compiling on Linux.
LLVM's CMake modules include a function `llvm_process_sources()`,
which (among other things) verifies that all source files in a
directory are either included in the list of source files to process,
or are included in a list `LLVM_OPTIONAL_SOURCES`.
SourceKit's CMake functions make use of this LLVM function, but do
not register any files as "optional". When attempting to configure
CMake to include SourceKit on a Linux host machine, source files
that are only included on Darwin host machines cause this function
to raise an error.
Mark Darwin-only SourceKit files as "optional" to avoid the error.
We want inputs for function names to follow SE-0021 with the exception
that a function with no arguments is spelled `foo()` instead of `foo`,
because we have no type to disambiguate with and it's not ambiguous with
a call in this context.
Internally, we use a filter name without underscores because we don't
want to introduce spurious matches to the `_` character which might be
part of identifiers.
For now, continue to accept the old names to ease the transition.
rdar://problem/24350800
The filter name of a function should match the spelling of the function
name according to the language except that we don't insert _ for unnamed
parameters because underscores are legal inside identifiers and we don't
want to introduce spurious matches (also, we keep the () on a
parameterless function for disambiguation).
rdar://problem/26118915
Remote metadata for closure contexts points to a capture descriptor.
We have a local copy of all capture descriptors. Translate the
address by recording the local and remote start address of
reflection metadata.
`sourcekitd-test` does not use LLVM's command line parsing utilities at
all, except to print a help message. However, the help message is
misleading: by default `llvm::cl` explains the `-help`, `-help-hidden`,
and `-version` options are available, but `sourcekitd-test` does not support
any of those.
https://bugs.swift.org/browse/SR-1421 tracks improving
`sourcekitd-test` help output, which will most likely involve migrating
it to LLVM's command line library. In the meantime, remove the
misleading "help" message.
Also, it should be noted that the return value of `1` returned after
printing the help message is not actually translated into a non-zero
exit code for the program. Add a "FIXME" to track the issue for now.
- Convert `Protocol.txt` to `Protocol.md`, and use valid Markdown
syntax.
- Spruce up the documentation in the "code completion": more details on
how to test via the REPL, clearer sentences, etc.
- Fix an error in which `sourcekitd-test -req=complete -offset=<offset>`
used the incorrect option `-cc-offset`.
Implement the ReflectionContext's implementation of:
swift_reflection_projectExistential.
First, we get the type info of the existential typeref - it should be a
record type info. If it's a class existential, it has trivial layout:
the first word is a pointer to the class instance. Otherwise, if the
value fits in the 3-word buffer of the existential container, it
trivially is also at the start of the container. Otherwise, the value is
off in a heap box somewhere, but the first word of the container is a
pointer to that box.
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
Fold UnitTest into the subkind, now that it's a bitself, and then remove
the unnecessary inheritance for IndexSymbol and its SourceKit indexing
equivalent.
Eventually we should just have one IndexSymbol, with all the
information. Once we kill FuncDeclIndexSymbol and can get rid of the
enum, we will regain most of the bytes we lost by inlining receiverUSR.
As a first step toward having more detailed "role" information, thread
through a SymbolRole bitset. For now it just contains the existing ref
vs. definition status.
...with a better message than the generic "older version of the
compiler" one, when we know it's actually a different version of
Swift proper.
This still uses the same internal module version numbers to check
if the module is compatible; the presentation of language versions
is a diagnostic thing only.
Speaking of module version numbers, this deliberately does NOT
increment VERSION_MINOR; it's implemented in a backwards-compatible
way.
This will only work going forwards, of course; all existing modules
don't have a short version string, and I don't feel comfortable
assuming all older modules we might encounter are "Swift 2.2".
rdar://problem/25680392
Closure context layout will depend on the instance itself as well
as the isa pointer, because instead of instantiating metadata for
closures that capture generic parameters, we store the substitutions
inside the context itself.
For classes, this entry point just reads the isa pointer, applies
the isa mask and proceeds down the metadata path.
For now, the only the latter is hooked up.
Also, use the instance layout entry point in swift-reflection-test,
so that we can dump the layout of a class instance and not the
lowering of the reference value.
These tools are always architecture-specific and always match the
architecture of the built Swift binary that links against
SwiftReflectionTest, so they can statically reference the size of their
pointer types.
This tool should test the usage from SwiftRemoteMirror dylib and
the C API, since that is the public interface from which we're
vending the remote reflection functionality.
- Improper handling of read() returning an incomplete read
- Update SwiftReflectionTest library for new builtin types section
Only tested manually so far; automated tests coming soon.
