The implementation of `#if hasAttribute(...)` only accepted declaration
attributes. It should also accept type attributes, like `@retroactive`.
Resolves rdar://125195051
Our standard conception of suppressible features assumes we should
always suppress the feature if the compiler doesn't support it.
This presumes that there's no harm in suppressing the feature, and
that's a fine assumption for features that are just adding information
or suppressing new diagnostics. Features that are semantically
relevant, maybe even ABI-breaking, are not a good fit for this,
and so instead of reprinting the decl with the feature suppressed,
we just have to hide the decl entirely. The missing middle here
is that it's sometimes useful to be able to adopt a type change
to an existing declaration, and we'd like older compilers to be
able to use the older version of the declaration. Making a type
change this way is, of course, only really acceptable for
@_alwaysEmitIntoClient declarations; but those represent quite a
few declarations that we'd like to be able to refine the types of.
Rather than trying to come up with heuristics based on
@_alwaysEmitIntoClient or other sources of information, this design
just requires the declaration to opt in with a new attribute,
@_allowFeatureSuppress. When a declaration opts in to suppression
for a conditionally-suppressible feature, the printer uses the
suppression serially-print-with-downgraded-options approach;
otherwise it uses the print-only-if-feature-is-available approach.
When determining whether a declaration should be considered unavailable at
runtime, ignore `@available` attributes for application extension platforms but
continue searching for other `@available` attributes that might still make the
declaration unavailable. This ensures corner cases like these are handled:
```
// Dubious, but allowed
@available(macOS, unavailable)
@available(macOSApplicationExtension, unavailable)
public func doublyUnavailableOnMacOSFunc() {}
// Expresses an uncommon, but valid constraint
@available(macCatalyst, unavailable)
@available(iOSApplicationExtension, unavailable)
public func confusingDiamondAvailabilityInheritanceFunc() {}
```
Use similar scheme as DeclAttribute.
* Create `BridgedTypeAttribute.createSimple()` and
`BridgedTypeAttributes.add()`, instead of
`BridgedTypeAttributes.addSimple()`
* Create `DeclAttributes::createSimple()` to align with `TypeAttribute`
The old TypeAttributes reprsentation wasn't too bad for a small number of
simple attributes. Unfortunately, the number of attributes has grown over
the years by quite a bit, which makes TypeAttributes fairly bulky even at
just a single SourceLoc per attribute. The bigger problem is that we want
to carry more information than that on some of these attributes, which is
all super ad hoc and awkward. And given that we want to do some things
for each attribute we see, like diagnosing unapplied attributes, the linear
data structure does require a fair amount of extra work.
I switched around the checking logic quite a bit in order to try to fit in
with the new representation better. The most significant change here is the
change to how we handle implicit noescape, where now we're passing the
escaping attribute's presence down in the context instead of resetting the
context anytime we see any attributes at all. This should be cleaner overall.
The source range changes around some of the @escaping checking is really a
sort of bugfix --- the existing code was really jumping from the @ sign
all the way past the autoclosure keyword in a way that I'm not sure always
works and is definitely a little unintentional-feeling.
I tried to make the parser logic more consistent around recognizing these
parameter specifiers; it seems better now, at least.
When building the Swift sources of the compiler many instances of the following
warning are emitted:
```
.../swift-project/swift/include/swift/AST/Attr.h:3075:10: warning: cycle detected while resolving 'iterator' in swift_name attribute for 'operator=='
bool operator==(iterator x) const { return x.attr == attr; }
^
```
These warnings were implemented in https://github.com/apple/swift/pull/37940
and they indicate that Swift compiler is failing to import a clang decl because
of circular references. Something about the structure of some operator
declarations in C++ headers triggers this warning. I'm not sure what the
correct long term fix for this is, but in the meantime the build log for the
compiler is getting drowned in these warnings which makes it difficult to
notice and find other diagnostics. Since these declarations are getting dropped
instead of imported, we can simply hide them from the Swift compiler in the
first place by guarding the declarations with `#ifdef __swift__`.
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
To match terminology used elsewhere in the compiler (e.g. "parsed accessor")
rename "original attributes" to "parsed atributes". Additionally, make sure the
attributes returned by `getParsedAttrs()` really are just the parsed ones by
skipping implicit attributes in addition to the ones expanded from macros.
The Attr.h is shared with SwiftCompilerSources through C++ interop and
C++ interop somehow crashes with libc++'s std::optional. So use legacy
llvm::Optional for now.
This attribute instructs the compiler that this function declaration
should be "import"ed from host environment. It's equivalent of Clang's
`__attribute__((import_module("module"), import_name("field")))`
This attribute instructs the compiler that this function declaration
should be "export"ed from this .wasm module. It's equivalent of Clang's
`__attribute__((export_name("name")))`
In order to support lazy typechecking during module emission for modules
containing specialized functions, the computation of generic signatures for
`@_specialized` attributes must be requestified.
Resolves rdar://115569606
This attribute can be attached to a noncopyable struct to specify that its
storage is raw, meaning the type definition is (with some limitations)
able to do as it pleases with the storage. This provides a basis for
implementing types for things like atomics, locks, and data structures
that use inline storage to store conditionally-initialized values.
The example in `test/Prototypes/UnfairLock.swift` demonstrates the use
of a raw layout type to wrap Darwin's `os_unfair_lock` APIs, allowing
a lock value to be stored inside of classes or other types without
needing a separate allocation, and using the borrow model to enforce
safe access to lock-guarded storage.
Attribute @_silgen_name is today only allowed to be used on functions, this change allows usage on globals as well. The motivation for that is to be able to "forward declare" globals just like it's today possible to do with functions (for the cases where it's not practical or convenient to use a bridging header).
Separately, this change also adds a @_silgen_name(raw: ...) syntax, which simply avoids mangling the name (by using the \01 name prefix that LLVM uses). The motivation for that is to be able to reference the "magic Darwin linker symbols" that can be used to look up section bounds (in the current dylib/module) -- those symbols don't use the underscore prefix in their mangled names.
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.
Some properties from `initializes(...)` list could be already initialized,
which means that Raw SIL lowering has to emit `destroy_addr` for them
before calling init accessor.
Add a special request that validates all of the property names
referenced by `initialized` and `accesses`, does the lookup and
returns underlying `VarDecl`s. This would also be used by DI.
