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.
Protocols with a superclass bound written as `protocol P where Self: C`
return null from getSuperclass(). Unqualified lookup only cares about
getSuperclassDecl(), so serialize that instead.
Fixes rdar://problem/124478687.
Deserialization may fail if a decl in a dependency changed type between the
time a swiftmodule was built and when it was imported. This can happen because
of changes to the SDK or use of C preprocessor macros. To help understand these
problems, note the specific types causing the mismatch when it leads to a
deserialization failure.
```
.../LibWithXRef.swiftmodule:1:1: error: reference to top-level
declaration 'foo' broken by a context change; the declaration kind of
'foo' from 'A' changed since building 'LibWithXRef'
1 │ A.foo
│ │ ├─ ...
│ ├─ note: a candidate was filtered out because of a type mismatch;
expected: '() -> ()', found: '(Int) -> Float'
```
Make sure we flush the diagnostics consumers to prevent the new
diagnostic style to buffer the deserialization errors without printing
them. These errors may be printed right before an `abort()`, which would
bypass the actual printing of the errors.
Take advantage of the new style to make these diagnostics more readable
as well.
```
.../LibWithXRef.swiftmodule:1:1: remark: reference to type 'MyType'
broken by a context change; 'MyType' was expected to be in 'A', but now
a candidate is found only in 'A_related'
1 │ A.MyType
│ ├─ remark: reference to type 'MyType' broken by a context change;
'MyType' was expected to be in 'A', but now a candidate is found only in
'A_related'
│ ├─ note: the type was expected to be found in module 'A' at
‘.../A.swiftmodule'
│ ├─ note: or expected to be found in the underlying module 'A'
defined at ‘.../module.modulemap'
│ ├─ note: the type was actually found in module 'A_related' at
‘.../A_related.swiftmodule'
│ ├─ note: the module 'LibWithXRef' was built with a Swift language
version set to 5.10 while the current invocation uses 4.1.50; APINotes
may change how clang declarations are imported
│ ├─ note: the module 'LibWithXRef' has enabled library-evolution; the
following file may need to be deleted if the SDK was modified:
‘.../LibWithXRef.swiftmodule'
│ ├─ note: declarations in the underlying clang module 'A' may be
hidden by clang preprocessor macros
│ ├─ note: the distributed module 'LibWithXRef' refers to the local
module 'A'; this may be caused by header maps or search paths
│ ╰─ note: the type 'MyType' moved between related modules; clang
preprocessor macros may affect headers shared between these modules
.../LibWithXRef.swiftmodule:1:1: note: could not deserialize type for
'foo()'
1 │ A.MyType
│ ╰─ note: could not deserialize type for 'foo()'
```
rdar://124700605
This appears to be a code path that wasn't previously stressed when
deserializing a bogus module, but now it is with NoncopyableGenerics, as
Copyable is often emitted as a builtin conformance.
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.
We preserve the current semantics that we have today by requiring that either all SILResultInfo are transferring or none are transferring. This also let me swap to @sil_transferring representation.
I did both of these things to fix SIL issues around transferring.
It also ensures that we now properly emit
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.
Recently, unexpected binary module sharing between compilers that had
inconsistent views of the `PlatformKind` enumeration caused me to spend several
days debugging undefined behavior in the compiler. We should validate that
enumeration values decoded during deserialization are valid, and fail fast when
they are not to make debugging this kind of issue less time consuming. This
change just validates the `PlatformKind` value decoded for an `AvailableAttr`,
but more of deserialization could be updated to do similar validation.
Resolves rdar://123770273
While working on #71425, I hit an assert indicating the `@_section` attribute was not
handled in `DeclDeserializer::deserializeDeclCommon`. This change adds the missing
deserialization for the `@_section` attribute.
The `ABI` headers had accidentally grown an `#include` into compiler headers,
allowing the enum constant values of the `ValueOwnership` enum to leak into
the runtime ABI. Sever this inappropriate relationship by declaring a separate
`ParameterOwnership` enum with ABI-stable values in the ABI headers, and
explicitly converting between the AST and ABI representation where needed.
Fixes rdar://122435628.
[transferring] Implement transferring result and clean up transferring param support by making transferring a bit on param instead of a ParamSpecifier.
Instead it is a bit on ParamDecl and SILParameterInfo. I preserve the consuming
behavior by making it so that the type checker changes the ParamSpecifier to
ImplicitlyCopyableConsuming if we have a default param specifier and
transferring is set. NOTE: The user can never write ImplicitlyCopyableConsuming.
NOTE: I had to expand the amount of flags that can be stored in ParamDecl so I
stole bits from TypeRepr and added some logic for packing option bits into
TyRepr and DefaultValue.
rdar://121324715
The reason why I am doing this is that I am going to be changing transferring to
not be a true ParamSpecifier. Instead, it is going to be a bit on Param that
changes the default ParamSpecifier used. That being said, I cannot use consuming
for this purpose since consuming today implies no implicit copy semantics, which
we do not want unless the user specifically asks for it by writing consuming.
Provide APIs needed by lifetime dependence diagnostics, namely LifetimeDependenceConvention.
Reorganize the APIs so it's easy to find related functionality which
API is responsible for which functionality.
Remove the originalFunctionConvention complexity. It is no longer
needed for lifetime dependence inference, and generally should be
avoided in SIL.
Add some placeholder FIXMEs because this not a good PR in which to
change existing functionality.
Test shadowed variable of same type
Fully type check caller side macro expansion
Skip macro default arg caller side expr at decl primary
Test macro expand more complex expressions
Set synthesized expression as implicit
Add test case for with argument, not compiling currently
Test with swiftinterface
Always use the string representation of the default argument
Now works across module boundary
Check works for multiple files
Make default argument expression work in single file
Use expected-error
Disallow expression macro as default argument
Using as a sub expression in default argument still allowed as expression macros behave the same as built-in magic literals
Not quite NFC because apparently the representation bleeds into what's
accepted in some situations where we're supposed to be warning about
conflicts and then making an arbitrary choice. But what we're doing
is nonsense, so we definitely need to break behavior here.
This is setting up for isolated(any) and isolated(caller). I tried
to keep that out of the patch as much as possible, though.
