…-or-nothing.
Disallow storing to subobjects of uninitialized objects.

… checking (#2862)
Per #257, we should be treating unformedness as all-or-nothing, rather than being a per-field or per-array-element property. Previously we initialized an array with no explicit initializer as containing a sequence of uninitialized values, but that led to crashes when attempting to access those values, as the checks for reading an uninitialized value only expected values to be uninitialized at the top level.
Also, we had existing tests that attempt to store to an element of an uninitialized array. We now detect that and treat it as UB during evaluation, rather than crashing due to trying to perform field access into an uninitialized value.
Finally, many of these problems can be detected statically, but the resolve_unformed pass wasn't catching them because it missed a few expression and declaration forms. Support for those cases has been added too. This causes the pass to recurse more often, and in particular our existing recursion test started hitting a stack overflow after this, so resolve_unformed now uses `RunWithExtraStack`. In passing, remove the need to explicitly tell `RunWithExtraStack` the return type, and infer it as the return type of the callable instead.

…tializer (#6934)
When a `var` is not explicitly given an initializer, initialize it in
one of two ways:
* If its type implements the new interface `Core.Default`, call
`Core.Default.Op` to initialize it.
* Otherwise, if its type implements `UnformedInit`, leave it in an
unformed state. For now, this is always an uninitialized state, but that
will change in the future.
* If neither of those apply, the `var` declaration is ill-formed.
This is a step towards implementing leads decision #6739 and proposals
#257 and #5913.
Assisted-by: Gemini 3.1 Pro via Antigravity
---------
Co-authored-by: Geoff Romer <gromer@google.com>

None of this area appears in the design today: `MaybeUnformed`, `unsafe as`,
`UnsafeAs`, `Core.Default`, `UnformedInit`, and `DefaultOrUnformed` have no hits
under `docs/`. Issue carbon-language#1993 has tracked that gap since 2022.
`values.md` gains the unformed state, alongside the initializing expressions it
builds on: what such a state must satisfy, the representation set and the values
in it, `Core.UnformedInit` with `StructT`, `Core.UnformedInvalid` and
`Core.UnformedNoop`, `Core.IsUnformed` and the rule for skipping destruction,
`Core.UnformedHarden` and the consistency rules on a hardened value, what a
variable declared with no initializer means, and `Core.MaybeUnformed(T)`.
`as_expressions.md` gains `unsafe as` and the rules for removing each type
qualifier. `classes.md` gains unsafe adapters, replacing a future work item
asking for a way to restrict adapter casts, and records that this revisits two
of the alternatives carbon-language#257 rejected. `assignment.md` says how an implementation
opts in to being called on an object that might be unformed. The summary in
`README.md` shrinks to point at `values.md`. `safety/README.md` cites
`unsafe as` as an example of a narrow unsafe operation.
Left for the memory safety model, and marked as future work rather than
described: the flow-sensitive checking that decides whether an object is known
to be initialized at a given point, the effects a function declares on its
caller's initialization state, and where hardening is applied, which depends on
both.
Assisted-by: Claude Code

None of this area appears in the design today: `MaybeUnformed`, `unsafe as`,
`UnsafeAs`, `Core.Default`, `UnformedInit`, and `DefaultOrUnformed` have no hits
under `docs/`. Issue carbon-language#1993 has tracked that gap since 2022.
`values.md` gains the unformed state, alongside the initializing expressions it
builds on: what such a state must satisfy, the representation set and the values
in it, `Core.UnformedInit` with `StructT`, `Core.UnformedInvalid` and
`Core.UnformedNoop`, `Core.IsUnformed` and the rule for skipping destruction,
`Core.UnformedHarden` and the consistency rules on a hardened value, what a
variable declared with no initializer means, and `Core.MaybeUnformed(T)`.
`as_expressions.md` gains `unsafe as` and the rules for removing each type
qualifier. `classes.md` gains unsafe adapters, replacing a future work item
asking for a way to restrict adapter casts, and records that this revisits two
of the alternatives carbon-language#257 rejected. `assignment.md` says how an implementation
opts in to being called on an object that might be unformed. The summary in
`README.md` shrinks to point at `values.md`. `safety/README.md` cites
`unsafe as` as an example of a narrow unsafe operation.
Left for the memory safety model, and marked as future work rather than
described: the flow-sensitive checking that decides whether an object is known
to be initialized at a given point, the effects a function declares on its
caller's initialization state, and where hardening is applied, which depends on
both.
Assisted-by: Claude Code

None of this area appears in the design today: `MaybeUnformed`, `unsafe as`,
`UnsafeAs`, `Core.Default`, `UnformedInit`, and `DefaultOrUnformed` have no hits
under `docs/`. Issue carbon-language#1993 has tracked that gap since 2022.
`values.md` gains the unformed state, alongside the initializing expressions it
builds on: what such a state must satisfy, the representation set and the values
in it, `Core.UnformedInit` with `StructT`, `Core.UnformedInvalid` and
`Core.UnformedNoop`, `Core.IsUnformed` and the rule for skipping destruction,
`Core.UnformedHarden` and the consistency rules on a hardened value, what a
variable declared with no initializer means, and `Core.MaybeUnformed(T)`.
`as_expressions.md` gains `unsafe as` and the rules for removing each type
qualifier. `classes.md` gains unsafe adapters, replacing a future work item
asking for a way to restrict adapter casts, and records that this revisits two
of the alternatives carbon-language#257 rejected. `assignment.md` says how an implementation
opts in to being called on an object that might be unformed. The summary in
`README.md` shrinks to point at `values.md`. `safety/README.md` cites
`unsafe as` as an example of a narrow unsafe operation.
Left for the memory safety model, and marked as future work rather than
described: the flow-sensitive checking that decides whether an object is known
to be initialized at a given point, the effects a function declares on its
caller's initialization state, and where hardening is applied, which depends on
both.
Assisted-by: Claude Code

None of this area appears in the design today: `MaybeUnformed`, `unsafe as`,
`UnsafeAs`, `Core.Default`, `UnformedInit`, and `DefaultOrUnformed` have no hits
under `docs/`. Issue carbon-language#1993 has tracked that gap since 2022.
`values.md` gains the unformed state, alongside the initializing expressions it
builds on: what such a state must satisfy, the representation set and the values
in it, `Core.UnformedInit` with `StructT`, `Core.UnformedInvalid` and
`Core.UnformedNoop`, `Core.IsUnformed` and the rule for skipping destruction,
`Core.UnformedHarden` and the consistency rules on a hardened value, what a
variable declared with no initializer means, and `Core.MaybeUnformed(T)`.
`as_expressions.md` gains `unsafe as` and the rules for removing each type
qualifier. `classes.md` gains unsafe adapters, replacing a future work item
asking for a way to restrict adapter casts, and records that this revisits two
of the alternatives carbon-language#257 rejected. `assignment.md` says how an implementation
opts in to being called on an object that might be unformed. The summary in
`README.md` shrinks to point at `values.md`. `safety/README.md` cites
`unsafe as` as an example of a narrow unsafe operation.
Left for the memory safety model, and marked as future work rather than
described: the flow-sensitive checking that decides whether an object is known
to be initialized at a given point, the effects a function declares on its
caller's initialization state, and where hardening is applied, which depends on
both.
Assisted-by: Claude Code