The logic here was unnecessary, the SourceRange gets converted to a
CharSourceRange in the function being called, which handles raw
identifiers correctly. 6.2-only since this is already fixed on main.
rdar://152273926
Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.
The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.
This patch fixes setLocationInfo() with some refactoring:
- getOriginalRange() is inlined into setLocationInfo(), so that the
generated buffer-handling logic is localized to that function. This
includes how it handles buffers generated for ReplacedFunctionBody.
- getOriginalLocation() is used in a couple of other places that only
care about macros expanded from the same buffer (so other generated
buffers not not relevant). This "macro-chasing" logic is simplified
and moved from ModuleDecl::getOriginalRange() to a free-standing
function, getMacroUnexpandedRange() (there is no reason for it to be
a method of ModuleDecl).
- GeneratedSourceInfo now carries an extra ClangNode field, which is
populated by getClangSwiftAttrSourceFile() when constructing
a generated buffer for an 'AttributeFromClang'. This could probably
be union'ed with one or more of the other fields in the future.
rdar://151020332
(cherry picked from commit 44aba1382d)
Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.
To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.
rdar://151206394
(cherry picked from commit 0f312adb92)
Make `getOriginalLocation` work with source ranges, and adjust the
cursor info logic to map the range into the original buffer. This
fixes the case where we were using bogus range lengths for macro
expansion decls.
rdar://151411756
Swift nodes imported from clang don't have doc comments carried over,
but IDEs are clever enough to fetch the comments from the associated
clang node. The swift node in the macro expansion from _SwiftifyImport
doesn't have a clang node directly associated with it however.
This patch adds the same comment from the clang node to the
_SwiftifyImport macro invocation node. Since the macro has access to
this node, it can easily copy over its leading trivia.
For now the comment is not altered at all, meaning @param still remains
even if the parmeter is removed.
rdar://151346977
(cherry picked from commit 6534b9b14f)
Introduce a new ASTWalker option for walking CustomAttrs and use it
for the placeholder scanner to ensure we can expand placeholders in
attribute arguments.
The diagnostic group documentation now point to the swift.org URL rather
than the toolchain path, so it no longer needs to be passed all the way
through sourcekitd.
Resolves rdar://151500502.
(cherry picked from commit 381684a389)
Previously we would insert StringRefs that reference the keys in the
map, but that breaks if the invocation ever gets copied. Switch to
`std::string`.
rdar://148130166
As SourceKit explicitly disables WMO, silence the diagnostic in this case (but leave it enabled for explicit non-WMO builds otherwise).
rdar://150596807
If a module has the same `public-module-name` as the module being
generated and its import is exported, merge it into the same generated
interface.
Fix various always-imported modules from being printed while here and
update all the tests that checked for them.
Resolves rdar://137887712.
(cherry picked from commit ddddc667c8)
`getType` here can return a null type if the queried expression isn't
part of the solution, which can currently happen for code completion.
I'm working on a more principled fix for this, but until then this is
a low-risk fix that will unblock the stress tester and can be
cherry-picked to 6.2.
rdar://149759542
Ensure we always expand extension macros after the top-level decl
for the given attached decl. This ensures correct unqualified lookup
behavior, and bans macro implementations from extending the
unqualified name (they're expected to use `providingExtensionsOf`
instead, which uses the qualified name).
rdar://148119538
For e.g implicit `buildExpression` calls, we have a location that
matches the argument, but we don't want to consider the result
builder type as the container type.
Element archetypes can occur here when mangling the USR for local
variables for e.g SourceKit cursor info, as well as for regular
compilation for things like lazy variables.
Update `getDeclTypeForMangling` to map local archetypes out of
context, using both the captured generic environments and the
archetypes present in the type. More work is needed to support lazy
variable though (now it crashes in SILGen).
This patch doesn't handle mangling standalone element archetypes for
e.g `printTypeUSR`, ideally we'd fix the clients there to not pass
local archetypes.
rdar://143077965
'ParserUnit' is used for analyzing syntax structures _mainly_ in
SourceKit.
Since we removed IfConfigDecl from AST, ParserUnit didn't
inclue any AST in #if ... #endif regions even for active region because
it used to consider all inactive. Instead, consider every region
"active" and include all the AST nodes.
rdar://117387631
`PrintOptions.InterfaceContentKind` was not initialized. Set it to
`InteraceMode::Private` by default, so SPI declarations and their `@_spi`
attribues are printed. This basically restores the behavior before
aba3b6c24e , and is align with
`AccessFilter` being `AccessLevel::Private` by default.
rdar://131726756
When importing C++ class template instantiations, Swift generates a type name for each instantiation. The generated names must be unique, since they are used for mangling.
If multiple different C++ types declare nested types with the same name, which are then used as template arguments, Swift was generating the same name for those template instantiations (e.g. `shared_ptr<Impl>` for different `Impl` types).
This change makes sure we use fully-qualified type names of template parameters when generating Swift type names for class template instantiations (e.g. `shared_ptr<MyNamespace.MyClass.Impl>`).
This fixes an assertion failure coming out of IRGen:
```
Assertion failed: (Buffer.empty() && "didn't claim all values out of buffer"), function ~ConstantInitBuilderBase, file ConstantInitBuilder.h, line 75.
```
rdar://141962480
Mangling a non-canonical type can run into
unexpected type sugar such as the newly introduced
LocatableType. USRs should be based on canonical
types anyway, so make sure we canonicalize before
mangling.
rdar://141168628
There are a bunch of AST nodes that can have
associated DeclNameLocs, make sure we cover them
all. I don't think this makes a difference for
`unwrapPropertyWrapperParameterTypes` since the
extra cases should be invalid, but for cursor info
it ensures we handle UnresolvedMemberExprs.
The logic here for completion wasn't actually
helping things since it would result in adding the
var overload to the system, which would result
in an ErrorType binding. We could turn the ErrorType
into a placeholder when resolving the overload,
but the simpler solution is to just allow CSGen
to turn the reference into a PlaceholderType. This
matches what we do for regular solving, and fixes
a crash with an IUO completion.
rdar://89369091
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
A recent PR (#77204) started to import C++ source locations into Swift.
This PR flips a switch so these locations are actually used more widely.
Now some of the diagnostic locations are changed, but they generally
improved the quality of the diagnostics, pointing out conformances
imported from Obj-C code right when they are declared.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
* [cxx-interop] Add Hashable conformance to imported enums
Previously, imported enums only conformed to RawRepresentable and Equatable,
so they could not be used as members of a Set or keys of a Dictionary.
This patch adds Hashable conformance to give them that ability,
as well as some test cases to clarify the expected behavior.
Existing test cases are updated to reflect this new conformance.
rdar://129713687
