We need to ensure that we recurse into the auxiliary decls in
`enumerateStoredPropertiesAndMissing` to pick up properties in
nested macro expansions. Also do the same in
`enumerateCurrentPropertiesAndAuxiliaryVars` and
`InitializablePropertiesRequest` to ensure the memberwise initializer
correctly handles this case. This would technically be ABI breaking,
but previously we would have just crashed in SILGen.
rdar://166908960
The same that some setups needs the `CMAKE_EXE_LINKER_FLAGS` propagated
for the test to compile plugins in the same configuration as the
compiler was using, the `CMAKE_SHARED_LINKER_FLAGS` needs to be
propagated if one wants to match the configuration used by CMake to
create libraries during the tests.
Add a new `config` value derived from `CMAKE_EXE_LINKER_FLAGS`, turn
that value into a substitution for the `Macros` tests, and use the
substibution in one test that creates a shared object. This allows the
shared object to be linked in the same way that it has been configured
in CMake.
Now accepted as
[SE-0489](https://github.com/ZevEisenberg/swift-evolution/blob/main/proposals/0489-codable-error-printing.md).
# To Do
- [x] confirm which version of Swift to use for the availability
annotations. Probably 6.3 at time of writing.
# Context
Re: [Swift forum
post](https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585/77),
where a discussion about future serialization tools in Swift prompted
Kevin Perry to suggest that some proposed changes could actually be made
in today's stdlib.
# Summary of Changes
Conforms `EncodingError` and `DecodingError` to
`CustomDebugStringConvertible` and adds a more-readable
`debugDescription`.
# Future Directions
This is a pared-down version of some experiments I did in
[UsefulDecode](https://github.com/ZevEisenberg/UsefulDecode). The
changes in this PR are the best I could do without changing the public
interface of `DecodingError` and `EncodingError`, and without modifying
the way the `JSON`/`PropertyList` `Encoder`/`Decoder` in Foundation
generate their errors' debug descriptions.
In the above-linked
[UsefulDecode](https://github.com/ZevEisenberg/UsefulDecode) repo, when
JSON decoding fails, I go back and re-decode the JSON using
`JSONSerialization` in order to provide more context about what failed,
and why. I didn't attempt to make such a change here, but I'd like to
discuss what may be possible.
# Examples
To illustrate the effect of the changes in this PR, I removed my changes
to stdlib/public/core/Codable.swift and ran my new test cases again.
Here are the resulting diffs.
##
`test_encodingError_invalidValue_nonEmptyCodingPath_nilUnderlyingError`
### Before
`invalidValue(234, Swift.EncodingError.Context(codingPath:
[GenericCodingKey(stringValue: "first", intValue: nil),
GenericCodingKey(stringValue: "second", intValue: nil),
GenericCodingKey(stringValue: "2", intValue: 2)], debugDescription: "You
cannot do that!", underlyingError: nil))`
### After
`EncodingError.invalidValue: 234 (Int). Path: first.second[2]. Debug
description: You cannot do that!`
## `test_decodingError_valueNotFound_nilUnderlyingError`
### Before
`valueNotFound(Swift.String, Swift.DecodingError.Context(codingPath:
[GenericCodingKey(stringValue: "0", intValue: 0),
GenericCodingKey(stringValue: "firstName", intValue: nil)],
debugDescription: "Description for debugging purposes", underlyingError:
nil))`
### After
`DecodingError.valueNotFound: Expected value of type String but found
null instead. Path: [0].firstName. Debug description: Description for
debugging purposes`
## `test_decodingError_keyNotFound_nonNilUnderlyingError`
### Before
`keyNotFound(GenericCodingKey(stringValue: "name", intValue: nil),
Swift.DecodingError.Context(codingPath: [GenericCodingKey(stringValue:
"0", intValue: 0), GenericCodingKey(stringValue: "address", intValue:
nil), GenericCodingKey(stringValue: "city", intValue: nil)],
debugDescription: "Just some info to help you out", underlyingError:
Optional(main.GenericError(name: "hey, who turned out the lights?"))))`
### After
`DecodingError.keyNotFound: Key \'name\' not found in keyed decoding
container. Path: [0].address.city. Debug description: Just some info to
help you out. Underlying error: GenericError(name: "hey, who turned out
the lights?")`
## `test_decodingError_typeMismatch_nilUnderlyingError`
### Before
`typeMismatch(Swift.String, Swift.DecodingError.Context(codingPath:
[GenericCodingKey(stringValue: "0", intValue: 0),
GenericCodingKey(stringValue: "address", intValue: nil),
GenericCodingKey(stringValue: "city", intValue: nil),
GenericCodingKey(stringValue: "birds", intValue: nil),
GenericCodingKey(stringValue: "1", intValue: 1),
GenericCodingKey(stringValue: "name", intValue: nil)], debugDescription:
"This is where the debug description goes", underlyingError: nil))`
### After
`DecodingError.typeMismatch: expected value of type String. Path:
[0].address.city.birds[1].name. Debug description: This is where the
debug description goes`
## `test_decodingError_dataCorrupted_nonEmptyCodingPath`
### Before
`dataCorrupted(Swift.DecodingError.Context(codingPath:
[GenericCodingKey(stringValue: "first", intValue: nil),
GenericCodingKey(stringValue: "second", intValue: nil),
GenericCodingKey(stringValue: "2", intValue: 2)], debugDescription:
"There was apparently some data corruption!", underlyingError:
Optional(main.GenericError(name: "This data corruption is getting out of
hand"))))`
### After
`DecodingError.dataCorrupted: Data was corrupted. Path: first.second[2].
Debug description: There was apparently some data corruption!.
Underlying error: GenericError(name: "This data corruption is getting
out of hand")`
## `test_decodingError_valueNotFound_nonNilUnderlyingError`
### Before
`valueNotFound(Swift.Int, Swift.DecodingError.Context(codingPath:
[GenericCodingKey(stringValue: "0", intValue: 0),
GenericCodingKey(stringValue: "population", intValue: nil)],
debugDescription: "Here is the debug description for value-not-found",
underlyingError: Optional(main.GenericError(name: "these aren\\\'t the
droids you\\\'re looking for"))))`
### After
`DecodingError.valueNotFound: Expected value of type Int but found null
instead. Path: [0].population. Debug description: Here is the debug
description for value-not-found. Underlying error: GenericError(name:
"these aren\\\'t the droids you\\\'re looking for")`
##
`test_encodingError_invalidValue_emptyCodingPath_nonNilUnderlyingError`
### Before
`invalidValue(345, Swift.EncodingError.Context(codingPath: [],
debugDescription: "You cannot do that!", underlyingError:
Optional(main.GenericError(name: "You really cannot do that"))))`
### After
`EncodingError.invalidValue: 345 (Int). Debug description: You cannot do
that!. Underlying error: GenericError(name: "You really cannot do
that")`
## `test_decodingError_typeMismatch_nonNilUnderlyingError`
### Before
`typeMismatch(Swift.String, Swift.DecodingError.Context(codingPath:
[GenericCodingKey(stringValue: "0", intValue: 0),
GenericCodingKey(stringValue: "address", intValue: nil),
GenericCodingKey(stringValue: "1", intValue: 1),
GenericCodingKey(stringValue: "street", intValue: nil)],
debugDescription: "Some debug description", underlyingError:
Optional(main.GenericError(name: "some generic error goes here"))))`
### After
`DecodingError.typeMismatch: expected value of type String. Path:
[0].address[1].street. Debug description: Some debug description.
Underlying error: GenericError(name: "some generic error goes here")`
## `test_encodingError_invalidValue_emptyCodingPath_nilUnderlyingError`
### Before
`invalidValue(123, Swift.EncodingError.Context(codingPath: [],
debugDescription: "You cannot do that!", underlyingError: nil))`
### After
`EncodingError.invalidValue: 123 (Int). Debug description: You cannot do
that!`
## `test_decodingError_keyNotFound_nilUnderlyingError`
### Before
`keyNotFound(GenericCodingKey(stringValue: "name", intValue: nil),
Swift.DecodingError.Context(codingPath: [GenericCodingKey(stringValue:
"0", intValue: 0), GenericCodingKey(stringValue: "address", intValue:
nil), GenericCodingKey(stringValue: "city", intValue: nil)],
debugDescription: "How would you describe your relationship with your
debugger?", underlyingError: nil))`
### After
`DecodingError.keyNotFound: Key \'name\' not found in keyed decoding
container. Path: [0]address.city. Debug description: How would you
describe your relationship with your debugger?`
## `test_decodingError_dataCorrupted_emptyCodingPath`
### Before
`dataCorrupted(Swift.DecodingError.Context(codingPath: [],
debugDescription: "The given data was not valid JSON", underlyingError:
Optional(main.GenericError(name: "just some data corruption"))))`
### After
`DecodingError.dataCorrupted: Data was corrupted. Debug description: The
given data was not valid JSON. Underlying error: GenericError(name:
"just some data corruption")`
##
`test_encodingError_invalidValue_nonEmptyCodingPath_nonNilUnderlyingError`
### Before
`invalidValue(456, Swift.EncodingError.Context(codingPath:
[GenericCodingKey(stringValue: "first", intValue: nil),
GenericCodingKey(stringValue: "second", intValue: nil),
GenericCodingKey(stringValue: "2", intValue: 2)], debugDescription: "You
cannot do that!", underlyingError: Optional(main.GenericError(name: "You
really cannot do that"))))`
### After
`EncodingError.invalidValue: 456 (Int). Path: first.second[2]. Debug
description: You cannot do that!. Underlying error: GenericError(name:
"You really cannot do that")`
These tests require the 'std_span' feature, but that feature was
previously only added in the test/Interop test suite. As a result these
tests would never run.
Removes -ignore-availability so that we get all the diagnostics.
This requires the functions to be made public, since the overloads are
_alwaysEmitIntoClient.
Renames the noescape* overloads lacking .nonescaping, and verifies that
their overloads are actually emitted. The rename did not cause them to
be emitted, the name was just misleading.
This test was already passing, but now it has better coverage.
rdar://156418990
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
The existing _SwiftifyImport macro is a peer macro, limiting it to only
emitting function wrappers in the same scope as the original function.
Protocols cannot contain function implementations, so these need to be
placed in a separate protocol extension instead. _SwiftifyImportProtocol
is an extension macro rather than a peer macro, to enable this
functionality.
Rather than operating on a single function, like _SwiftifyImport,
_SwiftifyImportProtocol takes information about multiple methods and
creates a single protocol extension with all wrappers in a one-shot
operation.
rdar://144335990
This adds a check in lit.local.cfg for whether the current C++ stdlib
contains the 'span' header. If so, the llvm-lit feature 'std_span' is
set. Also adds 'REQUIRES: std_span' to interop tests that include
'span'. This means we no longer have to choose between blanket disabling
`std::span` tests on all Linux distributions, or listing every Linux
distro with a libstdc++ version without `std::span` support as
unsupported.
I couldn't find any existing path to the MSVC stdlib in lit, and we
don't test versions of MSVC old enought to not support std::span
anyways, so 'std_span' is unconditionally enabled when targeting
windows-msvc.
rdar://161999160
rdar://161999174
rdar://162106580
rdar://162106619
rdar://162106643
rdar://162106653
rdar://162106722
rdar://162106747
Remove the DeclContext parameter from ResolveMacroRequest, we can now
retrieve the DeclContext either from the CustomAttr or macro expansion
expr/decl directly.
Macro implementation should receive only see the macro syntax (i.e.
`#macroName(...)` or `@macroName(...)` are operator folded, not other
syntax - the attached declration, member, etc.
rdar://162208759
Clients should be able to handle closures without a valid `in`
SourceLoc, let's avoid setting it to a recovery location. This avoids
crashing in cases where we set an `in` loc that's after the closure's
end loc.
The initializers for RawSpan and UnsafeRawBufferPointer take an
UnsafeRawPointer, so when the underlying function returns an
OpaquePointer we need to cast it first.
rdar://162091516
Although the type is unsafe, the count is marked `@safe`, and this use
of `unsafe` results in a warning (regardless of whether strict memory
safety is enabled or not).
Keep emitting `unsafe` when the pointer buffer is wrapped in Optional
for now however, because that is currently flagged as unsafe.
rdar://162416566
When shutting down, the plugin, we send SIGTERM, then wait(2) on it. But
we observed some cases the compiler waits for the plugin process exit
for long time.
To resolve that, send an empty message to the plugin and let them exit
itself.
rdar://160820381
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Thread the static build configuration (formed from language options) in
to the macro plugin handler, which will serialize it for use in the
macro implementation. test this with a simple macro that checks
whether a particular custom configuration (set via `-D`) is enabled or
not.
This required some re-layering, sinking the logic for building a
StaticBuildConfiguration from language options down into a new
swiftBasicSwift library, which sits on top of the C++ swiftBasic and
provides Swift functionality for it. That can be used by the C++
swiftAST to cache the StaticBuildConfiguration on the ASTContext,
making it available for other parts of ASTGen.
The test is implicitly using `async` main so the `SwiftStdlib 5.1`
checks weren't actually preventing it from exercising the concurrency
runtime. Just require the runtime to be present.
This test case failed in CI when using a strict diff, because the output
also contained the text "swift runtime: unknown backtracing setting
'warnings'". Switch to using FileCheck to ignore this output.
Since freestanding macro expansion buffer names include the line number
of their invocation, it can become quite fiddly to try to update a test
file with multiple macro expansions. This adds the option to use an
expected-expansion block and use a relative line number, nesting other
expected diagnostic statements inside this block.
Example syntax:
```swift
let myVar = #myMacro
/*
expected-expansion@-2:1{{
expected-error@13:37{{I can't believe you've done this}}
expected-note@14:38{{look at this and ponder your mistake}}
}}
*/
```
In Swift 6 and later, whitespace is no longer permitted between an
attribute name and the opening parenthesis. Update the parser so that
in Swift 6+, a `(` without preceding whitespace is always treated as
the start of the argument list, while a '(' with preceding whitespace is
considered the start of the argument list _only when_ it is unambiguous.
This change makes the following closure be parsed correctly:
{ @MainActor (arg: Int) in ... }
rdar://147785544
Also mark them as not executable, since they don't call `%target-run`.
This is needed in back deployment configurations where StringProcessing is
not supported.
Addresses rdar://159635486
The previous message was just suggesting unchecked Sendable, but instead
we should be suggesting to add final to the class. We also don't
outright suggest using unchecked Sendable -- following
https://github.com/swiftlang/swift/pull/81738 precedent.
Resolves rdar://155790695
Sema seems to be flagging inout expressions (e.g. &foo) in expression
macros as invalid, setting up a catch 22 where Sema emits an error when
a parameter has the '&' sigil and type checking fails when it doesn't.
This resolves the issue by allowing inout expressions inside macro
expansion expressions.
Resolves https://github.com/swiftlang/swift/issues/82369.
We can't assume that type-checking the expression macro in the
parameter will also fail if it fails at the call site since e.g
name lookup may differ. Make sure we only apply this logic to simple
literals.
rdar://154771596
