Commit Graph

45 Commits

Author SHA1 Message Date
Alex Lorenz
97c25ae854 [interop][SwiftToCxx] nested types are not yet supported so do not emit references to them 2023-08-02 13:03:05 -07:00
Becca Royal-Gordon
1318bf5bf5 [NFC] Begin adopting new diagnostics features 2023-07-19 13:06:51 -07:00
Evan Wilde
f3ff561c6f [NFC] add llvm namespace to Optional and None
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.
2023-06-27 09:03:52 -07:00
Alex Lorenz
74e87a9ae6 [interop][SwiftToCxx] do not expose move-only Swift types
Swift's consume semantics are not yet supported in C++
2023-05-06 07:12:46 -07:00
Alex Lorenz
c7836e3a8e [interop][SwiftToCxx] avoid emitting ambiguous C++ overloads
Just do an arity check for now
2023-05-05 17:07:43 -07:00
Alex Lorenz
bf35e3f55a [interop][SwiftToCxx] provide a clear unavailable message for protocol decls in C++ 2023-05-05 17:03:28 -07:00
Alex Lorenz
aff3568a12 [interop][SwiftToCxx] emit unavailable type stubs for top level types that could not be emitted in the C++ section of the generated header 2023-05-05 17:03:26 -07:00
Alex Lorenz
20704ec0f3 [interop][SwiftToCxx] do not expose enums with a protocol type associated value 2023-04-21 12:06:43 -07:00
Alex Lorenz
71ef7e8d3d [interop][SwiftToCxx] do not expose unsupported enums yet
This includes indirect enums, enums with multiple associated values, or enums whose associated value is a type we don't yet support
2023-04-20 18:05:00 -07:00
Alex Lorenz
f405fb0fa8 [interop][SwiftToCxx] do not expose @alwaysEmitIntoClient properties to C++ 2023-03-15 10:01:37 -07:00
Alex Lorenz
9f86ff9072 [interop][SwiftToCxx] explicitly tell the user that @objc decls can't be yet exposed to C++ 2023-03-13 18:16:36 -07:00
Alex Lorenz
3b7c92073b Merge pull request #64265 from hyp/eng/swift-stdlib-is-swift-whoda-thunk-it
[interop][SwiftToCxx] emit Swift's stdlib inside of 'swift' namespace
2023-03-10 06:40:11 -08:00
Alex Lorenz
0dc90d38c1 [interop][SwiftToCxx] emit Swift's stdlib inside of 'swift' namespace 2023-03-09 17:32:43 -08:00
Alex Lorenz
617ead4a9d [interop][SwiftToCxx] do not emit _Concurrency APIs in the C++ section of the generated header
Fixes an issue where actors exposed its unownedExecutor property with unsupported type.
2023-03-09 10:51:22 -08:00
Alex Lorenz
3adf16eb28 Merge pull request #64083 from hyp/eng/api-stdlib-arg-labels
[interop][SwiftToCxx] incorporate argument labels into Stdlib API nam…
2023-03-03 21:37:40 -08:00
Alex Lorenz
13a63f4b05 [interop][SwiftToCxx] incorporate argument labels into Stdlib API names in C++
This allows easier use and more wider API exposure from the Swift stdlib

In the future, all functions and method should incorporate argument labels, but it's not yet clear how
2023-03-03 14:15:48 -08:00
Alex Lorenz
1d3797308d [interop][SwiftToCxx] do not expose functions / properties that throw without the experimental feature 2023-03-02 15:22:36 -08:00
Alex Lorenz
8bce678200 [interop][SwiftToCxx] diagnose when certain generic decls can not yet be exposed to C++ 2023-02-28 09:17:31 -08:00
Alex Lorenz
28af8bef55 [interop][SwiftToCxx] make it possible to convert Swift String to a std::string in C++
This is done by exposing nested Index and UTF8View type in String. Nested types aren't
supported yet, so we need to employ a number of hacks to emit them.
2022-12-14 16:22:41 -08:00
Alex Lorenz
d0e5372fc0 [interop][SwiftToCxx] give explicit error for @alwaysEmitIntoClient exposed functions 2022-12-06 11:44:29 -08:00
Alex Lorenz
bd6367986e [interop][SwiftToCxx] report an error for attempts to explicitly expose 'async' functions to C++
also fixup distributed actor example in interop test
2022-11-03 13:46:52 -07:00
Alex Lorenz
0d754e1d3f [interop][SwiftToCxx] add support for exposing non-isolated actor declarations 2022-11-02 12:17:55 -07:00
Alex Lorenz
a949ca987e [interop][SwiftToCxx] do not expose actor classes in the generated header 2022-10-04 21:32:00 -07:00
Alex Lorenz
8de79390be [interop][SwiftToCxx] add @_expose(Cxx) attribute support
This attribute instructs the compiler that this declaration should be included in the generated C++ bindings
2022-08-24 10:14:07 -07:00
Alex Lorenz
fcdcb2a9f1 [interop][SwiftToC++] print C++ interface for top-level Swift functions 2022-03-09 14:53:12 -08:00
Alex Lorenz
e106551028 [NFC][interop] rename the PrintAsObjC library to PrintAsClang
We're starting to support emission of C++ header interfaces, so a language-agnostic name makes more sense
2022-01-20 11:31:58 -08:00
Anthony Latsis
c63b737e92 Collapse all indirect equivalents to ValueDecl::getBaseIdentifier 2020-03-29 00:36:01 +03:00
Anthony Latsis
d0ae3ee580 [AST] Replace FuncDecl::getName & EnumElementDecl::getName with ValueDecl::getBaseIdentifier 2020-03-29 00:35:51 +03:00
Fred Riss
259d78a350 Adapt to llvm.org StringRef API change 2020-03-13 19:08:22 +01:00
Jordan Rose
171ff440fc Remove swift::reversed in favor of llvm::reverse (#27610)
The former predates the latter, but we don't need it anymore! The
latter has more features anyway.

No functionality change.
2019-10-10 17:16:09 -07:00
Slava Pestov
0c5d52d860 AST: Introduce AbstractStorageDecl::get{Parsed,Opaque}Accessor()
Also, change visitOpaqueAccessors() to call getOpaqueAccessor() instead of
asserting if the expected accessor does not exist.
2019-08-02 19:34:43 -04:00
Slava Pestov
64c32c695b AST: Remove a few utility methods from AbstractStorageDecl
Since the return value of getAccessor() depends on mutable state, it
does not make sense in the request evaluator world. Let's begin by
removing some utility methods derived from getAccessor(), replacing
calls to them with calls to getAccessor().
2019-08-01 18:31:58 -04:00
Brent Royal-Gordon
1875783734 Use more robust Swift type names for error domains
getErrorDomainStringForObjC() now includes the parent types in the error domain string. Its implementation does not support generic types or private discriminators, but those types can’t be PrintAsObjC’d anyway, so we should never see them.
2018-12-21 15:45:23 -08:00
Brent Royal-Gordon
1a6ca82d6b [NFC] Extract helper for making NSError domains
Avoids having to coordinate changes in two different parts of the compiler.
2018-12-21 15:30:35 -08:00
Slava Pestov
840c97d794 AST: Remove hasAccess() checks 2018-09-05 16:45:31 -07:00
Jordan Rose
537954fb93 [AST] Rename several DeclContext methods to be clearer and shorter (#18798)
- getAsDeclOrDeclExtensionContext -> getAsDecl

This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.

- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)

These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point.  The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.

- getAsProtocolExtensionContext -> getExtendedProtocolDecl

Like the above, this didn't return the ExtensionDecl; it returned its
extended type.

This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
2018-08-17 14:05:24 -07:00
Slava Pestov
615d068d63 Sema: Replace some uses of getBaseIdentifier() with userFacingName() 2018-03-14 22:26:58 -07:00
Stephan Tolksdorf
79cef77ce0 [AST] Remove unused LazyResolver parameter from ObjC-selector-related Decl methods 2018-02-27 01:11:35 +01:00
Jordan Rose
1c651973c3 Excise "Accessibility" from the compiler (2/3)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.

This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
2017-08-28 11:34:44 -07:00
Jordan Rose
5f30eac288 Excise "Accessibility" from the compiler (1/3)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.

This commit changes the names of methods, fields, a few local
variables, and even a swift-ide-test flag. The full list is below.

accessibilityForDiagnostics -> accessLevelForDiagnostics
checkAccessibility -> checkAccess
checkGenericParamAccessibility -> checkGenericParamAccess
checkTypeAccessibility -> checkTypeAccess
checkWitnessAccessibility -> checkWitnessAccessibility
computeAccessibility -> computeAccessLevel
computeDefaultAccessibility -> computeDefaultAccessLevel
fixItAccessibility -> fixItAccess
getAccessibilityString -> getAccessLevelString
getAccessibilityStrictly -> getAccessLevelStrictly
getAccessibilityUID -> getAccessLevelUID
getActualAccessibility -> getActualAccessLevel
getDefaultAccessibility -> getDefaultAccessLevel
getMaxAccessibility -> getMaxAccessLevel
getOverridableAccessibility -> getOverridableAccessLevel
getRawStableAccessibility -> getRawStableAccessLevel
getSetterAccessibility -> getSetterFormalAccess
hasAccessibility -> hasAccess
hasDefaultAccessibility -> hasDefaultAccessLevel
inferAccessibility -> inferAccessLevel
inferDefaultAccessibility -> inferDefaultAccessLevel
inferSetterAccessibility -> inferSetterAccessLevel
overwriteAccessibility -> overwriteAccess
overwriteSetterAccessibility -> overwriteSetterAccess
printAccessibility -> printAccess
requiredAccessibilityForDiagnostics -> requiredAccessForDiagnostics
resolveAccessibility -> resolveAccessControl
setAccessibility -> setAccess
setSetterAccessibility -> setSetterAccess
setDefaultAndMaxAccessibility -> setDefaultAndMaxAccess
validateAccessibility -> validateAccessControl

Accessibility -> AccessLevel
AccessibilityFilter -> AccessFilter
IgnoreAccessibility -> IgnoreAccessControl
NL_IgnoreAccessibility -> NL_IgnoreAccessControl
PrintAccessibility -> PrintAccess
PrintInternalAccessibilityKeyword -> PrintInternalAccessKeyword
SetterAccessibility -> SetterAccessLevel

setterAccessibility -> setterAccess
storedPropertyAccessibility -> storedPropertyAccess

-print-accessibility -> -print-access
2017-08-28 11:11:57 -07:00
Jordan Rose
eb9f047ad8 [PrintAsObjC] Handle the importer's compatibility typealiases. (#10042)
These are TypeAliasDecls whose Clang nodes are not TypedefNameDecls.
This worked all right for classes, but dropped the tag keyword
(e.g. 'struct') for tag decls with names of their own, and didn't
print any name at all for C types that used the
typedef-for-anonymous-tag pattern.

rdar://problem/32514335
2017-06-01 15:28:44 -07:00
Jordan Rose
325a96983e [AST] Preparations for removal of getName on ValueDecl (#9969)
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
2017-05-28 19:04:19 -07:00
Jordan Rose
c0ccdb1626 Change getBaseName to return DeclBaseName instead of Identifier (#9968)
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.

For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.

Unify approach to printing declaration names

Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
2017-05-28 17:55:03 -07:00
Nathan Hawes
0223be25f9 SwiftNameTranslation.cpp: Guard call to VD->getFormalAccess() with a hasAccessibility() check. 2017-02-21 16:04:43 -08:00
Nathan Hawes
0dc0985f45 Move SwiftNameTranslation implementation out of Decl.cpp and into its own file.
Also fix code formatting issues and simplify the code in USRGeneration.cpp based on review comments in PR #7670.
2017-02-21 14:54:31 -08:00