[6.0] Consistently treat let properties as immutable within the type checker #73664
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…value This operation determines whether a particular storage declaration, when accessed from a particular location, is mutable or not. It has a particular semantic that `let` declarations, when accessed from an initializer, are considered mutable even though they can only be assigned. There is similar logic for init accessors. Tease apart "truly mutable" from "initializable because we're in an initializer", introducing AbstractStorageDecl::mutability() to represent all three states. isSettable() remains available as a thin shim over mutability() and all clients are unchanged thus far, making this a no-op refactoring.
Stored `let` properties of a struct, class, or actor permit 'inout' modification within the constructor body after they have been initialized. Tentatively remove this rule, only allowing such `let` properties to be initialized (assigned to) and not treated as `inout`. Fixes rdar://127258363.
…nces as lvalues As we do with references to initializable local lets, teach the type checker to produce ASTs where member references to initializable instance property lets (e.g., within an initializer) treat the `let` as an lvalue and then immediately load. This modeling addresses a source compatibility issue uncovered in swift-syntax, where code that *technically* has a use-before-definition on a `let` property in an initializer wasn't diagnosed as such because the loaded value wasn't actually used for anything.
|
@swift-ci please test |
hborla
approved these changes
May 16, 2024
nate-chandler
added a commit
to nate-chandler/swift
that referenced
this pull request
May 31, 2024
The flag had been used in test/SILOptimizer/definite_init_inout_super_init.swift because SILGen generated invalid SIL which would only be diagnosed during DI. Thanks to swiftlang#73664 , this is diagnosed before SILGen. One other test case use (test/PrintAsObjC/extensions.swift) remains.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation: Rework our handling of let properties so that they are treated as rvalues uniformly except when they are being assigned to. This moves the inout/mutating checking up into the type checker, whereas it was previously handled at a later stage in Definite Initialization. This change allows overload resolution to correctly reject a call to a
mutablefunction on aletproperty in an initializer, and therefore choose another option, which is a more appropriate way to model the language semantics.Original PR: #73609
Radar/issue: rdar://127258363, a source compatibility issue with
AsyncIteratorProtocol.next()'s default implementation that required this semantic improvement.Risk: Medium-low. This changes the modeling of references to
letinstance properties within an initializer and uninitialized localletproperties within the type checker to make them rvalues unless they're the target of an assignment (in which case they remain lvalues). The type checker, however, still creates an AST that treats them as lvalues (that are immediately loaded), because later compiler passes (SILGen and DI) expect this modeling. The overall effect is expected to be very small, and should only serve to make some ill-formed programs (where the type checker picked amutablefunction on an lvalue) well-formed or diagnose in an earlier phase of the compiler.Reviewed by: @xedin