Skip to content

Fix typos in EmbeddedRuntime.swift #82215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix typos in EmbeddedRuntime.swift #82215

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions stdlib/public/core/EmbeddedRuntime.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ public struct ClassMetadata {
└──────────────┴──────────────────────────────────────────────┘

If the highest bit (doNotFreeBit) is set, the behavior of dropping the last reference (release operation where
refcount ends up being 0) is altered to avoid calling free() on the object (deinit is still run). This is crutial for
refcount ends up being 0) is altered to avoid calling free() on the object (deinit is still run). This is crucial for
class instances that are promoted by the compiler from being heap-allocated to instead be located on the stack
(see swift_initStackObject).

Expand All @@ -67,7 +67,7 @@ public struct ClassMetadata {
_ContiguousArrayStorage can be promoted to __StaticArrayStorage with the HeapObject header emitted directly by the
compiler and refcount field directly set to immortalRefCount | doNotFreeBit (see irgen::emitConstantObject).

Tne immortalRefCount is additionally also used as a placeholder value for objects (heap-allocated or stack-allocated)
The immortalRefCount is additionally also used as a placeholder value for objects (heap-allocated or stack-allocated)
when they're currently inside their deinit(). This is done to prevent further retains and releases inside deinit from
triggering deinitialization again, without the need to reserve another bit for this purpose. Retains and releases in
deinit() are allowed, as long as they are balanced at the end, i.e. the object is not escaped (user's responsibility)
Expand Down