Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
It appears that a6ebd3083d changed the behavior of `-fno-modules-validate-system-headers` (aka. `DisableModulesValidateSystemDependencies`) in conjunction with `-fmodules-validate-once-per-build-session`: Before that change, `-fno-modules-validate-system-headers` needed to be passed for `-fmodules-validate-once-per-build-session` to have any effect (we were always validating system dependencies if `-fno-modules-validate-once-per-build-session` was not set). After the change, `-fno-modules-validate-once-per-build-session` causes system dependencies to never be validated, independent of the build session timestamp.
This change should have no effect on Xcode because it adds `-fmodules-validate-system-headers` to the compiler arguments for Swift files, which overrides `SearchPathOpts.DisableModulesValidateSystemDependencies = true;`
Function body macros allow one to introduce a function body for a
particular function, either providing a body for a function that
doesn't have one, or wholesale replacing the body of a function that
was written with a new one.
This will allow us to run two different completion kinds and deliver results from both of them.
Also: Compute a unified type context for global lookup. Previously, we always used the expected type context of the last lookup. But really, we should be considering all possible types from all constraint system solutions when computing code completion results from the cache.
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.
The compiler knows (from a macro declaration) what freestanding macro
role a macro implementation is expected to implement. Pass that through
to the macro expansion code itself, rather than guessing based on the
protocol conformances of the implementation type. We already use this
approach with attached macros, so this is more of the same.
Eliminates a crash and improves diagnostics when the freestanding macro
role and its implementation are out of sync, fixing rdar://110418969.
Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
* Factor out ASTContext plugin loading to newly introduced 'PluginLoader'
* Insert 'DependencyTracker' to 'PluginLoader'
* Add dependencies right before loading the plugins
rdar://104938481
Driver uses its path to derive the plugin paths (i.e.
'lib/swift/host/plugins' et al.) Previously it was a constant string
'swiftc' that caused SourceKit failed to find dylib plugins in the
toolchain. Since 'SwiftLangSupport' knows the swift-frontend path,
use it, but replacing the filename with 'swiftc', to derive the plugin
paths.
rdar://107849796
Make a single 'PluginRegistry' and share it between SwiftASTManager,
IDEInspectionInstance, and CompileInstance. And inject the plugin
registry to ASTContext right after 'CompilerInstance.setup()'
That way, all sema-capable ASTContext in SourceKit share a single
PluginRegistry.
This hooks up the cursor info infrastructure to be able to pass through multiple, ambiguous results. There are still minor issues that cause solver-based cursor info to not actually report the ambiguous results but those will be fixed in a follow-up PR.
This allows us to model the `ResolvedCursorInfo` types as a proper type hierarchy instead of having to store all values in the base `ResolvedCursorInfo` type.
rdar://102853071
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
Each macro expansion buffer was getting parsed twice: once by
ParseSourceFileRequest (which is used by unqualified name lookup) and
once to parse the expression when type-checking the expanded macro.
This meant that the same code had two ASTs. Hilarity ensures.
Stop directly invoking the parser on macro-expanded code. Instead, go
through ParseSourceFileRequest *as is always the right way*, and dig
out the expression we want.
We need swiftsourcedocinfo for cursor info and to be able to reuse the ASTContext from code completion for cursor info, we need to also retrieve the sourcedocinfo for code completion requests.
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.
This brings up the ability to compute cursor info results using the completion-like type checking paradigm, which an reuse ASTContexts and doesn’t need to type check the entire file.
For now, the new implementation only supports cursor info on `ValueDecl`s (not on references) because they were easiest to implement. More cursor info kinds are coming soon.
At the moment, we only run the new implementation in a verification mode: It is only invoked in assert toolchains and when run, we check that the results are equivalent to the old implementation. Once more cursor info kinds are implemented and if the SourceKit stress tester doesn’t find any verification issues, we can enable the new implementation, falling back to the old implementation if the new one didn’t produce any results.
