…for extensions. This change also removes @implementation(CategoryName); you should attach the category name to the @objc attribute instead. And there are small changes to how much checking the compiler will do on an @objc @implementation after the decl checker has discovered a problem with it.
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
Add the machinery to support suppression of inference of conformance to
protocols that would otherwise be derived automatically.
This commit does not enable any conformances to be suppressed.
Ensure that we're properly parsing suppressed-conformance constraints
in expression contents and in metatypes. This allows types like `any
~Copyable` in expression context as well as types like `any
~Copyable.Type`.
While we're here, ensure that existentials that involve
suppressed-conformance constraints are spelled with `any`.
Fixes rdar://123728228.
Implement parser and type-expression folding semantics for invertible
protocols, so that one can write (e.g.) `[any ~Copyable]` as a type
within expression context.
Fixes rdar://125201146.
The flag -experimental-skip-non-inlinable-function-bodies-without-types
is built in the emit-module-separately phase to quickly extract the API
of the target module. It is designed to not skip functions with nested
types as these are used by LLDB.
This logic relies on a simple heuristic to find nested type. Let's make
sure it detects tyealiases and actors.
rdar://120928396
Pitch - https://github.com/apple/swift-evolution/pull/2305
Changes highlights:
dependsOn(paramName) and dependsOn(scoped argName) syntax
dependsOn(paramName) -> copy lifetime dependence for all parameters/self except
when we have Escapable parameters/self, we assign scope
lifetime dependence.
Allow lifetime dependence on parameters without ownership modifier.
Always infer copy lifetime dependence except when we have
Escapable parameters/self, we infer scope lifetime dependence.
Allow lifetime dependence inference on parameters without ownership modifier.
The compiler treats version tuples that are all zeros as empty, or the same as
not having a version. Diagnose attempts to specify all-zeroes versions in
attributes and availability queries to prevent surprising behavior.
Resolves rdar://124661151
Previously, diagnostics for arguments of platform conditions (e.g.
'os(macOS)') used to point the condition name position instead of the
argument position.
Adjust the position to the start of the argument.
rdar://124160048
Lifetime specifiers before parameter names were disallowed in Swift 3 (SE-0031).
`isolated`, `transferring` and `_const` got added after Swift 3 without a diagnostic to disallow them before parameter names.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
* Record each IfConfig clause location info in SourceFile
* Update SILProfiler to handle them
* Update SwiftLangSupport::findActiveRegionsInFile() to use the recorded
regions instead of walking into AST to find #if regions
rdar://118082146
We can use part of the new infrastructure if we simply handle abstract
conformances to Copyable, which is what we'd get upon lookup for a
nominal in the old world. This means that we can merge diagnostics for
the containment test together, and fix differences with deinit
diagnostics.
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.
The goal is to have a lightweight way to pass an unapplied
diagnostic to general routines. Constructing a Diagnostic
is quite expensive as something we're potentially doing in
hot paths, as opposed to just when we're actually emitting
the diagnostic. This design allows the expense to be delayed
until we need it.
I've also optimized the Diagnostic constructor to avoid
copying arguments unnecessarily; this is a relatively small
expense, since arguments are POD, but there's really no good
reason not to do it.
