Commit Graph

12 Commits

Author SHA1 Message Date
Doug Gregor
731f58443c Address review feedback on AbstractConformance in ProtocolConformanceRef 2025-03-23 20:54:39 -07:00
Doug Gregor
4395537fa0 Introduce the @safe attribute as described in the opt-in safety checking proposal 2025-01-23 07:47:17 -08:00
Doug Gregor
8bb5bbedbc Implement an unsafe expression to cover uses of unsafe constructs
Introduce an `unsafe` expression akin to `try` and `await` that notes
that there are unsafe constructs in the expression to the right-hand
side. Extend the effects checker to also check for unsafety along with
throwing and async operations. This will result in diagnostics like
the following:

    10 |   func sum() -> Int {
    11 |     withUnsafeBufferPointer { buffer in
    12 |       let value = buffer[0]
       |                   |     `- note: reference to unsafe subscript 'subscript(_:)'
       |                   |- warning: expression uses unsafe constructs but is not marked with 'unsafe'
       |                   `- note: reference to parameter 'buffer' involves unsafe type 'UnsafeBufferPointer<Int>'
    13 |       tryWithP(X())
    14 |       return fastAdd(buffer.baseAddress, buffer.count)

These will come with a Fix-It that inserts `unsafe` into the proper
place. There's also a warning that appears when `unsafe` doesn't cover
any unsafe code, making it easier to clean up extraneous `unsafe`.

This approach requires that `@unsafe` be present on any declaration
that involves unsafe constructs within its signature. Outside of the
signature, the `unsafe` expression is used to identify unsafe code.
2025-01-10 10:39:14 -08:00
Doug Gregor
bb7a563e6c Switch async for-each loop over to _nextElement and drop @rethrows.
This couples together several changes to move entirely from
`@rethrows` over to typed throws:

* Use the `Failure` type to determine whether an async for-each loop
will throw, rather than depending on rethrows checking

* Introduce a special carve-out for `rethrows` functions that have a
generic requirement on an `AsyncSequence` or `AsyncIteratorProtocol`,
which uses that requirement's `Failure` type as potentially being part
of the thrown error type. This allows existing generic functions like
the following to continue to work:

    func f<S: AsyncSequence>(_: S) rethrows

* Switch SIL generation for the async for-each loop from the prior
`next()` over to the typed-throws version `_nextElement`.

* Remove `@rethrows` from `AsyncSequence` and `AsyncIteratorProtocol`
entirely. We are now fully dependent on typed throws.
2024-01-25 16:04:43 -08:00
Slava Pestov
afa5a8874c AST: Add AnyFunctionType::hasEffect() 2021-02-28 22:21:08 -05:00
Slava Pestov
09dedaa5fe Sema: Start abstracting out the 'effect' in rethrows-checking logic
For now, this is NFC, but it lays the groundwork for implementing
'reasync'.
2021-02-17 18:34:18 -05:00
swift-ci
06513524e9 Merge pull request #35940 from AnthonyLatsis/eof-warn 2021-02-12 11:37:40 -08:00
Anthony Latsis
39649161d0 Gardening: See to some missing newline warnings 2021-02-12 17:00:47 +03:00
Slava Pestov
e2d4eb64e0 Sema: Fix recursion into associated conformances when checking for rethrows
The logic for recursively expanding protocol requirements was broken.
Instead, let's do the recursive visitation when evaluating a
conformance to a @rethrows protocol.
2021-02-10 16:30:30 -05:00
Slava Pestov
f3c9b00298 AST: Allow empty protocols to be @rethrows 2021-02-09 00:11:01 -05:00
Slava Pestov
a1d483faf3 AST: Move some code from ProtocolConformance.cpp to Effects.cpp / TypeCheckEffects.cpp 2021-02-09 00:11:01 -05:00
Slava Pestov
547057380f AST: Split off Effects.cpp from Decl.cpp 2021-02-09 00:11:01 -05:00