Commit Graph

14 Commits

Author SHA1 Message Date
Doug Gregor
c241e782e0 Use SwiftIfConfig to determine where to emit new parser diagnostics 2024-08-22 22:33:53 -07:00
Doug Gregor
fc5ba4c7d5 Revert "Use SwiftIfConfig to determine where to emit new parser diagnostics"
This reverts commit 1da2631c4e.
2024-08-22 09:22:20 -07:00
Doug Gregor
1da2631c4e Use SwiftIfConfig to determine where to emit new parser diagnostics 2024-08-17 22:48:18 -07:00
Doug Gregor
a844f4fa0b Free memory allocated in Swift from Swift, not C++ 2024-08-02 10:04:29 -07:00
Doug Gregor
d06e40877f Re-implement SourceFile::getIfConfigClauseRanges on top of SwiftIfConfig
The SwiftIfConfig library provides APIs for evaluating and extracting
the active #if regions in source code. Use its "configured regions" API
along with the ASTContext-backed build configuration to reimplement the
extraction of active/inactive regions from the source.

This approach has the benefit of being effectively stateless: where the
existing solution relies on the C++ parser recording all of the `#if`
clauses it sees as it is parsing (and then might have to sort them later),
this version does a scan of source to collect the list without requiring
any other state. The newer implementation is also conceptually cleaner,
and can be shared with other clients that have their own take on the
build configuration.

The primary client of this information is the SourceKit request that
identifies "inactive" regions within the source file, which IDEs can
use to grey out inactive code within the current build configuration.
There is also some profiling information that uses it. Those clients
should be unaffected by this under-the-hood change.

For the moment, I'm leaving the old code path in place for compiler
builds that don't have swift-syntax. This should be considered
temporary, and that code should be removed in favor of request'ifying
this function and removing the incrementally-built state entirely.
2024-08-02 10:04:27 -07:00
Rintaro Ishizaki
2f7aa428db [Macros] In-process plugin server
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.

* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
  swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
  `lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
  This has one `swift_inproc_plugins_handle_message` entry point that
  receives a message and return the response.
* In the compiler
  * Add `-in-process-plugin-server-path` front-end option, which specifies
    the `SwiftInProcPluginServer` shared library path.
  * Remove `LoadedLibraryPlugin`, because all library plugins are managed
    by `SwiftInProcPluginServer`
  * Introduce abstract `CompilerPlugin` class that has 2 subclasses:
    * `LoadedExecutablePlugin` existing class that represents an
      executable plugin
    * `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
  * Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
    difference between executable plugins and library plugins are now
    abstracted by `CompilerPlugin`
2024-06-17 11:36:52 -07:00
Rintaro Ishizaki
f5aca556dd [Macros] Don't use 'ExportedSourceFile' for macro definition checking
`macro` declarations often appear in files that does not contain any
expansions (e.g. `.swiftinterface`). So invoking `SwiftParser` for the
entire file is a waste.
2024-04-24 22:05:15 -07:00
Apollo Zhu
ea35e1bac2 Use Swift Syntax for checking literals 2024-02-06 15:02:15 -08:00
Konrad `ktoso` Malawski
5acd366c98 [macros] allow forwarding generic arguments through macro declarations (#71271)
* [macros] allow forwarding generic arguments through macro declarations

[macros] add more tests for generic argument forwarding in macro declarations

* [macros] correct replacement picking logic
2024-02-06 03:56:20 -08:00
Rintaro Ishizaki
47f18d492e [ASTGen] Move regex literal parsing from SwiftCompilerSources to ASTGen
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.

Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
2023-11-16 10:59:23 -08:00
Rintaro Ishizaki
fb08a92f48 [ASTGen] Infrastructure to implment ASTGen Incrementally
* 'ASTGenVisitor' has a reference to a legacy C++ Parser configured for
  ASTGen.
* If 'ASTGenVisitor' encounters a AST node that hasn't been migrated,
  call parse(Decl|Stmt|Expr|Type) to parse the position using the legacy
  parser.
* The legacy parser calls ASTGen's
  'swift_ASTGen_build(Decl|Stmt|Expr|Type)' for each ASTNode "parsing"
  (unless the call is not directly from the ASTGen.)

rdar://117151886
2023-11-12 21:43:08 -08:00
Hamish Knight
6afde8a6d2 Remove CBasicBridging and CASTBridging
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
2023-10-30 23:49:56 +00:00
Hamish Knight
356cf31d83 [ASTGen] Migrate onto some BasicBridging types
Migrate onto BridgedStringRef, and the
BasicBridging equivalents of BridgedSourceLoc
and BridgedArrayRef.
2023-10-30 23:49:53 +00:00
Rintaro Ishizaki
e01df929c2 [swift-parse-test] A parser performance check utility
```
% swift-parse-test -swift-parser -lib-parse -n 20 ../swift-syntax/Sources
files count: 228
total bytes: 5662399
total lines: 158428
iteration: 20
----
parser:  SwiftParser
wall clock time (ms): 3848
cpu time (ms): 3843
throughput (byte/sec): 355824
throughput (line/sec): 41225
----
parser:  libParse
wall clock time (ms): 296
cpu time (ms): 290
throughput (byte/sec): 4715281
throughput (line/sec): 546303
```
2023-10-28 20:23:26 -07:00