diff --git a/.agents/skills/builtins/SKILL.md b/.agents/skills/builtins/SKILL.md index 1fce41d39313..60c1dabff8a0 100644 --- a/.agents/skills/builtins/SKILL.md +++ b/.agents/skills/builtins/SKILL.md @@ -75,10 +75,10 @@ Inside the matching `SemIR` type instruction (such as `FloatType` or `FloatLiteralType`). Use pre-established semantic helpers: - - `TypeParam`: Ensures different parameters resolve to identical type - structures (e.g., generic constraint matching). - - `AnyInt`, `AnyFloat`, `AnySizedInt`, `AnySizedFloat`, `CharCompatible`, - `StdInitializerList`, `NoReturn`. + - `TypeParam`: Ensures different parameters resolve to identical type + structures (e.g., generic constraint matching). + - `AnyInt`, `AnyFloat`, `AnySizedInt`, `AnySizedFloat`, `CharCompatible`, + `StdInitializerList`, `NoReturn`. 2. **Map Literal Name & Register Constraint Signature**: Declare a `BuiltinInfo` constant inside `namespace BuiltinFunctionInfo` matching the macro-defined @@ -94,13 +94,13 @@ Inside 3. **Establish Compile-Time Residency Status**: Update `BuiltinFunctionKind::IsCompTimeOnly` to determine if a call requires compile-time evaluation: - - **Checked/Diagnostics Primitives**: Return `true` immediately. Runtime - lowering of these is illegal (e.g. `IntConvertFloatChecked`). - - **Runtime Primitives**: Return - `AnyLiteralTypes(sem_ir, arg_ids, return_type_id)` to enforce that - expressions involving unsized literal values (like `IntLiteral` or - `FloatLiteral`) are evaluated exclusively at compile-time (as they lack - runtime representation). + - **Checked/Diagnostics Primitives**: Return `true` immediately. Runtime + lowering of these is illegal (e.g. `IntConvertFloatChecked`). + - **Runtime Primitives**: Return + `AnyLiteralTypes(sem_ir, arg_ids, return_type_id)` to enforce that + expressions involving unsized literal values (like `IntLiteral` or + `FloatLiteral`) are evaluated exclusively at compile-time (as they lack + runtime representation). --- @@ -111,10 +111,10 @@ execute compile-time computations: 1. **Implement Constant Evaluation Logic**: - - Handle the builtin case inside `MakeConstantForBuiltinCall` (which - processes the compile-time execution of the call). - - Confirm type validation phase is `Phase::Concrete` to reject incomplete - bindings: + - Handle the builtin case inside `MakeConstantForBuiltinCall` (which + processes the compile-time execution of the call). + - Confirm type validation phase is `Phase::Concrete` to reject incomplete + bindings: ```cpp case SemIR::BuiltinFunctionKind::IntConvertFloat: { @@ -126,24 +126,24 @@ execute compile-time computations: } ``` - - Extract inputs safely from local value stores (e.g. - `context.ints().Get(arg.int_id)` or `context.floats().Get(arg.float_id)`). - - Leverage high-precision LLVM mathematical structures (`llvm::APInt`, - `llvm::APFloat`, `llvm::APSInt`) to handle custom bits and signedness - safely. + - Extract inputs safely from local value stores (e.g. + `context.ints().Get(arg.int_id)` or `context.floats().Get(arg.float_id)`). + - Leverage high-precision LLVM mathematical structures (`llvm::APInt`, + `llvm::APFloat`, `llvm::APSInt`) to handle custom bits and signedness + safely. 2. **Diagnose Invalid Parameters or Exceptions**: - - Define compile-time diagnostics inside - [kind.def](../../../toolchain/diagnostics/kind.def): + - Define compile-time diagnostics inside + [kind.def](../../../toolchain/diagnostics/kind.def): ```cpp // toolchain/diagnostics/kind.def CARBON_DIAGNOSTIC_KIND(IntTooLargeForFloatType) ``` - - Emplace localized diagnostic formatting messages where they are caught in - `eval.cpp`: + - Emplace localized diagnostic formatting messages where they are caught in + `eval.cpp`: ```cpp CARBON_DIAGNOSTIC(IntTooLargeForFloatType, Error, @@ -152,14 +152,14 @@ execute compile-time computations: context.emitter().Emit(loc_id, IntTooLargeForFloatType, val, dest_type_id); ``` - - Return `SemIR::ErrorInst::ConstantId` to gracefully abort invalid constant - generation rather than crashing the compiler. + - Return `SemIR::ErrorInst::ConstantId` to gracefully abort invalid constant + generation rather than crashing the compiler. 3. **Fast-Path Range Limits**: - - Before evaluating expensive math operations on giant exponents (e.g. - `1.0e1000000`), executing range limits check against `dest_width + 64` - (sized) or `IntStore::MaxIntWidth` (unsized) is mandatory to prevent - out-of-bounds calculations and compile-time memory exhaustion. + - Before evaluating expensive math operations on giant exponents (e.g. + `1.0e1000000`), executing range limits check against `dest_width + 64` + (sized) or `IntStore::MaxIntWidth` (unsized) is mandatory to prevent + out-of-bounds calculations and compile-time memory exhaustion. --- diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 93907c63e2c5..c3d0ff03be93 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -51,7 +51,7 @@ repos: # Re-run markdown linting to fix any issues caused by doc style and TOC. This # is very fast, so it shouldn't be problematic to run twice. - repo: https://github.com/rvben/rumdl-pre-commit - rev: v0.2.22 + rev: v0.2.30 hooks: - id: rumdl args: [--fix] diff --git a/.rumdl.toml b/.rumdl.toml index a0ea3867f020..b20844e416dc 100644 --- a/.rumdl.toml +++ b/.rumdl.toml @@ -43,6 +43,7 @@ style = "one-or-ordered" # Unordered list indentation [MD007] +style = "fixed" indent = 4 [MD077] diff --git a/proposals/p000142-unicode-source-files.md b/proposals/p000142-unicode-source-files.md index 81b8bcc4a714..cb843adec837 100644 --- a/proposals/p000142-unicode-source-files.md +++ b/proposals/p000142-unicode-source-files.md @@ -103,15 +103,15 @@ The choice to require NFC is really four choices: 1. Equivalence classes: we use a canonical normalization form rather than a compatibility normalization form or no normalization form at all. - - If we use no normalization, invisibly-different ways of representing the - same glyph, such as with pre-combined diacritics versus with diacritics - expressed as separate combining characters, or with combining characters - in a different order, would be considered different characters. - - If we use a canonical normalization form, all ways of encoding diacritics - are considered to form the same character, but ligatures such as `ffi` are - considered distinct from the character sequence that they decompose into. - - If we use a compatibility normalization form, ligatures are considered - equivalent to the character sequence that they decompose into. + - If we use no normalization, invisibly-different ways of representing the + same glyph, such as with pre-combined diacritics versus with diacritics + expressed as separate combining characters, or with combining characters + in a different order, would be considered different characters. + - If we use a canonical normalization form, all ways of encoding diacritics + are considered to form the same character, but ligatures such as `ffi` are + considered distinct from the character sequence that they decompose into. + - If we use a compatibility normalization form, ligatures are considered + equivalent to the character sequence that they decompose into. For a fixed-width font, a canonical normalization form is most likely to consider characters to be the same if they look the same. Unicode annexes diff --git a/proposals/p002665-semicolons-terminate-statements.md b/proposals/p002665-semicolons-terminate-statements.md index 73095ef09298..aac34d7e4492 100644 --- a/proposals/p002665-semicolons-terminate-statements.md +++ b/proposals/p002665-semicolons-terminate-statements.md @@ -43,10 +43,10 @@ Statements need some system for separation. There are two main options for this: 1. Require semicolons to terminate statements. 2. Automatically determine where statements terminate. - - Some languages, such as Python, define a syntax where a newline terminates - statements. - - Other languages, such as Javascript, require semicolons but define rules - for semicolon insertion. + - Some languages, such as Python, define a syntax where a newline terminates + statements. + - Other languages, such as Javascript, require semicolons but define rules + for semicolon insertion. Although Carbon's design currently assumes semicolons are required, it hasn't been directly addressed by a proposal. diff --git a/proposals/p003720-member-binding-operators.md b/proposals/p003720-member-binding-operators.md index c133fb6b46af..26a6acbf1956 100644 --- a/proposals/p003720-member-binding-operators.md +++ b/proposals/p003720-member-binding-operators.md @@ -235,12 +235,12 @@ How does this arise? Note that `C.F` is `__C_F` with type `__TypeOf_C_F`, and `C.Static` is `__C_Static` with type `__TypeOf_C_Static`. 2. It then looks at the expression to the left of the `.`: - - If it is a facet value, the "member binding to type" (`BindToType`) - operator is applied. - - If it is a reference expression, the "member binding to reference" - (`BindToRef`) operator is applied. - - If it is a value expression, the "member binding to value" (`BindToValue`) - operator is applied. + - If it is a facet value, the "member binding to type" (`BindToType`) + operator is applied. + - If it is a reference expression, the "member binding to reference" + (`BindToRef`) operator is applied. + - If it is a value expression, the "member binding to value" (`BindToValue`) + operator is applied. 3. The result of the member binding has a type that implements the call interface. diff --git a/proposals/p003762-merging-forward-declarations.md b/proposals/p003762-merging-forward-declarations.md index 14d476c7be9f..42aeb74a3c33 100644 --- a/proposals/p003762-merging-forward-declarations.md +++ b/proposals/p003762-merging-forward-declarations.md @@ -193,7 +193,7 @@ declaration, only access modifiers are valid (see When considering whether a declaration is allowed, we apply the rules: 1. A declaration should always add new information. - - No declarations after a definition. + - No declarations after a definition. 2. Only one library can declare an entity without `extern`. 3. Support moving declarations between already-imported `api` files without affecting compilation of client libraries. diff --git a/proposals/p003938-exporting-imported-names.md b/proposals/p003938-exporting-imported-names.md index 172449719e78..be2b6e6a2cf9 100644 --- a/proposals/p003938-exporting-imported-names.md +++ b/proposals/p003938-exporting-imported-names.md @@ -259,15 +259,15 @@ on advantages and disadvantages for each option. Advantages: - - No need to teach developers they cannot (don't need to) `export` locally - introduced names. + - No need to teach developers they cannot (don't need to) `export` locally + introduced names. Disadvantages: - - Although the restricted placement might imply placement is tied to - specific libraries, that's not the case. This could mislead developers. - - In theory, we could enforce this, but then we could end up breaking - code if the path a name is imported through changes. + - Although the restricted placement might imply placement is tied to + specific libraries, that's not the case. This could mislead developers. + - In theory, we could enforce this, but then we could end up breaking + code if the path a name is imported through changes. 2. `export name` with other declarations @@ -276,15 +276,15 @@ on advantages and disadvantages for each option. Advantages: - - `import` remains very special. - - Makes it unambiguous that names valid for `export` are already imported. + - `import` remains very special. + - Makes it unambiguous that names valid for `export` are already imported. Disadvantages: - - Prevents placing `export name` next to the import that is expected to add - the name. - - Means `export import` and `export name` will be in different sections: no - single place to look for re-exports. + - Prevents placing `export name` next to the import that is expected to add + the name. + - Means `export import` and `export name` will be in different sections: no + single place to look for re-exports. 3. No ordering for `export name` @@ -292,11 +292,11 @@ on advantages and disadvantages for each option. Advantages: - - Maximum flexibility, HOA rule. + - Maximum flexibility, HOA rule. Disadvantages: - - Most inconsistent with the desire to treat `import` as special. + - Most inconsistent with the desire to treat `import` as special. We're choosing option (2). The name lookup issues avoided by requiring `export` be below `import` directives seem worthwhile. diff --git a/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md b/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md index 068f838bebba..10f5e19956f2 100644 --- a/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md +++ b/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md @@ -184,11 +184,11 @@ Carbon supports **decimal and hexadecimal** floating-point literals. Example: 1. Decimal: - - `123.456` - - `1.23456e791` + - `123.456` + - `1.23456e791` 2. Hexadecimal: - - `0x1.Ap123` + - `0x1.Ap123` #### Literal types diff --git a/proposals/scripts/template.md b/proposals/scripts/template.md index 98443c0bf3f8..366ccabe7379 100644 --- a/proposals/scripts/template.md +++ b/proposals/scripts/template.md @@ -29,7 +29,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception 1. Copy this template to `new.md`, and create a commit. 2. Create a GitHub pull request, to get a pull request number. - - Add the `proposal draft` label to the pull request. + - Add the `proposal draft` label to the pull request. 3. Rename `new.md` to `/proposals/p####.md`, where `####` should be the pull request number. 4. Update the title of the proposal (the `TODO` on line 1). diff --git a/utils/vscode/README.md b/utils/vscode/README.md index e71508e4b2e2..9aa678e3dead 100644 --- a/utils/vscode/README.md +++ b/utils/vscode/README.md @@ -15,9 +15,9 @@ This extension is currently experimental, and being developed alongside Carbon. 1. Download and install a `carbon` [release](https://github.com/carbon-language/carbon-lang/releases). - - By default, the extension will look for `carbon` under `./bazel-bin`. This - is for developers actively working on Carbon and running VS Code inside a - [carbon-lang](https://github.com/carbon-language/carbon-lang) clone. + - By default, the extension will look for `carbon` under `./bazel-bin`. This + is for developers actively working on Carbon and running VS Code inside a + [carbon-lang](https://github.com/carbon-language/carbon-lang) clone. 2. Install the [Carbon Language extension](https://marketplace.visualstudio.com/items?itemName=carbon-lang.carbon-vscode). 3. Configure the installed path to `carbon`. diff --git a/utils/vscode/development.md b/utils/vscode/development.md index d20c2aa9fcab..776fe1e90218 100644 --- a/utils/vscode/development.md +++ b/utils/vscode/development.md @@ -37,8 +37,8 @@ This installs `vsce` and `ovsx` to `/usr/local/bin`. Ensure that - Using the UI: 1. `npm install && vsce package -o carbon.vsix && realpath carbon.vsix` - - This installs dependencies, builds the VSIX file, and prints the - path. + - This installs dependencies, builds the VSIX file, and prints the + path. 2. Open the [command palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette) and select "Extensions: Install from VSIX...". @@ -51,9 +51,9 @@ This installs `vsce` and `ovsx` to `/usr/local/bin`. Ensure that 1. `npm install && vsce package -o carbon.vsix && realpath carbon.vsix` 2. Go to https://marketplace.visualstudio.com/manage/publishers/carbon-lang - - We use `infra-role@carbon-lang.dev` for publishing; the GitHub - account `CarbonInfraBot` can also be used for login. Contact leads - if you require access. + - We use `infra-role@carbon-lang.dev` for publishing; the GitHub + account `CarbonInfraBot` can also be used for login. Contact leads + if you require access. 3. Next to the extension name, click the "..." and select "Update". 4. Select the `carbon.vsix` file. 3. Build and publish to the Open VSX Registry by following the