The main Swift repository contains the source code for the Swift compiler and standard library, as well as related components such as SourceKit (for IDE integration), the Swift regression test suite, and implementation-level documentation.

Compiler Architecture

As a whole, the Swift compiler is principally responsible for translating Swift source code into efficient, executable machine code. However, the Swift compiler front-end also supports a number of other tools, including IDE integration with syntax coloring, code completion, and other conveniences. This document provides a high-level description of the major components of the Swift compiler:

Parsing: The parser is a simple, recursive-descent parser (implemented in lib/Parse) with an integrated, hand-coded lexer. The parser is responsible for generating an Abstract Syntax Tree (AST) without any semantic or type information, and emit warnings or errors for grammatical problems with the input source.

The Swift standard library encompasses a number of data types, protocols and functions, including fundamental data types (e.g., Int, Double), collections (e.g., Array, adidas Burgundy Advantage Cf Sneaker Women's Collegiate white White Dictionary) along with the protocols that describe them and algorithms that operate on them, characters and strings, and low-level primitives (e.g., UnsafeMutablePointer). The implementation of the standard library resides in the stdlib/public subdirectory within the Satin Black Fierce Rope PUMA Puma Womens EP BqYSx4tn8, which is further subdivided into:

Standard library core: The core of the standard library (implemented in stdlib/public/core), including the definitions of all of the data types, protocols, functions, etc.

Runtime: The language support runtime (implemented in stdlib/public/runtime), which is layered between the compiler and the core standard library. It is responsible for implementing many of the dynamic features of the language, such as casting (e.g., for the as! and as? operators), type metadata (to support generics and reflection), and memory management (object allocation, reference counting, etc.). Unlike higher-level libraries, the runtime is written mostly in C++ or (where needed for interoperability) Objective-C.

The Swift standard library is written in Swift, but because it is the lowest-level Swift code in the stack—responsible for implementing the core data types on which other Swift code is built—it is a bit different from normal Swift code. Some of the differences include:

Access to compiler builtins: The Builtin module, which is only generally accessible to the standard library, provides compiler builtin functions (e.g., to directly create SIL instructions) and data types (e.g., “raw” pointers, primitive LLVM integer types) needed to implement the data types that are fundamental to programming in Swift.

Visibility is often managed by convention: Standard library declarations often need to have greater visibility than one would generally like, due to the way in which the standard library is compiled and optimized. For example, private modifiers are never used. More importantly, it is common to need to make something public even when it is not intended as part of the public interface. In such cases, one should use a leading underscore to indicate that the public API is meant to be private. The policy for access control in the standard library is documented in docs/AccessControlInStdlib.rst.

Repetitive code uses gyb: gyb is a simple tool for generating repetitive code from a template that is used often in the standard library. For example, it is used to create the definitions of the various sized integer types (Int8, Int16, Int32, Int64, etc.) from a single source.

Testing is tightly coupled with the compiler: The standard library and the compiler evolve together and are tightly coupled. Changes in core data types (e.g., Cf Sneaker adidas Burgundy Collegiate white Women's Advantage White Array or Advantage Sneaker Cf White Women's white Collegiate adidas Burgundy Int) can require compiler-side changes, and vice-versa, so the standard library test suite is stored within the same directory structure as the compiler, in test/stdlib and validation-test/stdlib.