Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Custom attributes were not printed because they are marked
'UserInaccesible'.
* Make CustomAttr 'RejectByParser' instead of 'UserInaccessible'
* Remove special treatment for Result Builder attributes
* Load implicit modules in module/header interface gen requests
rdar://79927502
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Hoist `iterateHeaps` into the `RemoteProcess` protocol, requiring an
implementation on all platforms. If the platform is unable to implement
heap traversal, it would be possible to simply leave the callback
uncalled.
Be more careful about memory queries, we may receive invalid memory
addresses.
In the "next" branch, set_size has been made protected. Instead, users
can use resize_for_overwrite, optionally followed by truncate, to
handle the same use cases more safely.
This adds some documentation about swift-inspect and how to build it on
Windows, which requires additional flags to locate the SwiftRemoteMirror
library from the toolchain.
This adds an initial port to Windows which allows inspection of the
processes. It is not possible to port `dump-arrays` or
`dump-concurrency` due to the need to iterate the heap. This still
allows for gaining some insight into the metadata and protocol caches.
Fix the many typos and missing `)` instances. Replace the inline array
removal with explicit duplication due to the behaviour of `#if`. This
allows the tool to build after the changes for the refactoring.
This restructures and refactors the project to split up the
implementation into smaller fragments. The majority of the operations
are portable: the ones which are not require iterating the heap
allocations which is not guaranteed to be a portable operation.
Additionally, the `Inspector` class is renamed into `RemoteProcess`
which is also converted to a protocol to allow adding in an
implementation for other targets. The inspection operations are split
off into individual files to make it easier to follow. Take the
opportunity to use `@main` for the entry point.
Filter name for completion item is always used. Also, for cached items,
they are used multiple times for filtering. So precomputing and caching
it improves performance.
rdar://84036006
Convert 'ContextFreeCodeCompletionResult' constructor overloads to
'create()' factory methods. This is the consistent interface with
'CodeCompletionString'. NFC
[CodeCompletion] Make ExpectedTypeContext a class with explicit getters/setters
This simplifies debugging because you can break when the possible types are set and you can also search for references to `setPossibleType` to figure out where the expected types are being set.
This separates it from `libSwiftScan` and allows us to build this library without building much of the rest of the compiler.
Also refactor `utils/build-parser-lib` into `utils/build-tooling-libs` which builds both SwiftSyntaxParser and SwiftStaticMirror.
Internal configurations targeting Darwin employ ThinLTO to
improve compiler performance, however using it on all executable
causes build time to increase with no matching benefit.
To reduce build times in such configurations, we allow some
ancillary targets to opt out of LLVM IR optimizations when linking
ThinLTO with ld64 (e.g. tools used for bootstrapping or debugging the
Swift compiler) -- this behaviour is opt in through a new flag
`--swift-tools-ld64-lto-codegen-only-for-supporting-targets`.
Addresses rdar://76702687
