carbon-language/carbon-lang
1
0
Fork 0
mirror of https://github.com/carbon-language/carbon-lang.git synced 2026-09-24 18:40:16 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity

Update to latest rumdl release and enable another option (#7483)

Browse Source 
The `style = "fixed"` is partially implied by `indent = 4`, but not
fully in some specific cases. There were also bugs in fully applying it
that are now fixed, and so we can specify it explicitly to get rumdl to
canonicalize nested list indentation more thoroughly.

Assisted-by: Antigravity with Gemini
This commit is contained in:
Chandler Carruth
2026-07-10 16:16:28 +00:00
committed by GitHub
parent 55dcf66584
commit de8b03faa3
12 changed files with 78 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/builtins/SKILL.md
+30 -30
View File
@@ -75,10 +75,10 @@ Inside
the matching `SemIR` type instruction (such as `FloatType` or
`FloatLiteralType`). Use pre-established semantic helpers:
- `TypeParam<I, T>`: Ensures different parameters resolve to identical type
structures (e.g., generic constraint matching).
- `AnyInt`, `AnyFloat`, `AnySizedInt`, `AnySizedFloat`, `CharCompatible`,
`StdInitializerList`, `NoReturn`.
- `TypeParam<I, T>`: 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.
---
.pre-commit-config.yaml
+1 -1
View File
@@ -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]
.rumdl.toml
+1
View File
@@ -43,6 +43,7 @@ style = "one-or-ordered"
# Unordered list indentation
[MD007]
style = "fixed"
indent = 4
[MD077]
proposals/p000142-unicode-source-files.md
+9 -9
View File
@@ -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
proposals/p002665-semicolons-terminate-statements.md
+4 -4
View File
@@ -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.
proposals/p003720-member-binding-operators.md
+6 -6
View File
@@ -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.
proposals/p003762-merging-forward-declarations.md
+1 -1
View File
@@ -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.
proposals/p003938-exporting-imported-names.md
+14 -14
View File
@@ -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.
proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md
+3 -3
View File
@@ -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
proposals/scripts/template.md
+1 -1
View File
@@ -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).
utils/vscode/README.md
+3 -3
View File
@@ -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`.
utils/vscode/development.md
+5 -5
View File
@@ -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