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.
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.
Introduce the experimental feature `ParserDiagnostics`, which emits
diagnostics from the new Swift parser *first* for a source file. If
that produces any errors, we suppress any diagnostics emitted from the
C++ parser.
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.
Introduce a new behavior when printing references to modules with an
`export_as` definition. Use the `export_as` name in the public swiftinterface
and the real module name in the private swiftinterface.
This has some limits but should still be an improvement over the current
behavior. First, the we use the `export_as` names only for references to clang
decls, not Swift decls with an underlying module defining an `export_as`.
Second, we always print the `export_as` name in the public swiftinterface,
even in the original swiftinterface file when the `export_as` target is likely
not know, so that generated swiftinterface is still broken.
This behavior is enabled by the flags `-enable-experimental-feature ModuleInterfaceExportAs`
or the `SWIFT_DEBUG_USE_EXPORTED_MODULE_NAME_IN_PUBLIC_ONLY` env var. We may
consider turning it on by default in the future.
rdar://98532918
Introduces a concept of a dependency scanning action context hash, which is used to select an instance of a global dependency scanning cache which gets re-used across dependency scanning actions.
`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
Prepare to accept the `ipi` argument to the `-library-level` flag. IPI
stands for Internal Programming Interface and would describe a module
that's not to be distributed outside of its project.
In the future, the compiler could use that information to report when a
distributed module (api or spi) imports publicly a module that's not
distributed.
rdar://102435183
Introduce an experimental option `BuiltinMacros` that takes the magic
literals (`#file`, `#line`, `#function`, etc.) after type checking and
processes the original source for the expression using the build
syntactic macro system in the swift-syntax library. At present, the
result of expansion is printed to standard output, but it's enough to
verify that we're able to find the corresponding syntax node based on
the C++ AST.
Introduce `MacroExpansionExpr` and `MacroExpansionDecl` and plumb it through. Parse them in roughly the same way we parse `ObjectLiteralExpr`.
The syntax is gated under `-enable-experimental-feature Macros`.
Instead, stimulate users to follow the referenced bug reporting guidelines,
which contain all the necessary information. We’d rather encourage attempts
at reducing issues before attaching Xcode projects. This is an accompaniment
to https://github.com/apple/swift-org-website/pull/158.
Global actors have been an accepted language feature for a couple of compiler releases now, but the feature definition was associated with the `--enable-experimental-concurrency` flag. This caused some `.swiftinterface`s containing global actor declarations to be unparsable because the logic for surrounding declarations with the `$GlobalActors` feature guard was incomplete (for example, classes with a global actor attribute were not guarded even though the declarations of global actor types were).
Rather than trying to fix the logic of `usesFeatureGlobalActors()`, enable it by default.
Adds a test that demonstrates that modules defining and using public global actors produce module interfaces that can be parsed successfully.
Resolves rdar://100150703
