Prepare docs split for v3 #163
Conversation
WalkthroughThe pull request introduces significant updates to the VitePress configuration and documentation for the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (59)
website/.vitepress/theme/utils/versioning.ts (1)
Line range hint
24-26: Fix regex pattern to support RC versions.The current regex pattern
/^v\d+$/won't match "v3-rc", which will cause routing issues for the RC version. The pattern needs to be updated to support RC versions.Here's the fix:
- if (/^v\d+$/.test(prefix)) { + if (/^v\d+(?:-rc)?$/.test(prefix)) {website/v2/guide/troubleshooting.md (2)
19-19: Enhance video accessibility attributes.The video element should include additional accessibility attributes for better user experience.
-<video controls src="/expand-macro-recursively.mp4" title="Title"></video> +<video + controls + src="/expand-macro-recursively.mp4" + title="How to expand macros recursively using Rust Analyzer" + aria-label="Demonstration of expanding macros using Rust Analyzer" +></video>
11-11: Minor grammar improvements needed.A few small grammatical adjustments would improve readability:
-Suppose you see a compile error coming from the code generated by a macro. The error message is not very informative because it points to some code inside of the macro that you don't see. +Suppose you see a compile error coming from the code generated by a macro. The error message is not very informative because it points to some code inside the macro that you don't see. -In this case, try expanding the macro using Rust Analyzer's command ["Expand macro recursively"](https://rust-analyzer.github.io/manual.html#expand-macro-recursively). It works for any kind of macro including attribute macros. +In this case, try expanding the macro using Rust Analyzer's command ["Expand macro recursively"](https://rust-analyzer.github.io/manual.html#expand-macro-recursively). It works for any kind of macro, including attribute macros.Also applies to: 13-13
🧰 Tools
🪛 LanguageTool
[style] ~11-~11: This phrase is redundant. Consider using “inside”.
Context: ...ormative because it points to some code inside of the macro that you don't see. In this ...(OUTSIDE_OF)
website/v2/guide/inspecting.md (2)
1-3: Add a comma for better readability.Consider adding a comma after "purposes" to improve the sentence flow:
-If you want to inspect the values set in the builder for debugging purposes you can leverage the [`#[builder(derive(...))]`](../reference/builder#derive) attribute to derive the [`Debug`](https://doc.rust-lang.org/stable/std/fmt/trait.Debug.html) trait for your builder. +If you want to inspect the values set in the builder for debugging purposes, you can leverage the [`#[builder(derive(...))]`](../reference/builder#derive) attribute to derive the [`Debug`](https://doc.rust-lang.org/stable/std/fmt/trait.Debug.html) trait for your builder.🧰 Tools
🪛 LanguageTool
[uncategorized] ~3-~3: Possible missing comma found.
Context: ...values set in the builder for debugging purposes you can leverage the [`#[builder(derive...(AI_HYDRA_LEO_MISSING_COMMA)
33-33: Consider adding a brief Clone example.The Clone trait mention is helpful, but a small code example showing its practical usage could be valuable for completeness.
Example addition:
let builder1 = example().name("Bon".to_owned()); let builder2 = builder1.clone();website/v2/guide/patterns/fallible-builders.md (4)
1-6: Enhance the introduction with more context and examples.The introduction could be more helpful by:
- Adding a brief explanation of why input validation is important (e.g., ensuring data integrity)
- Providing simple examples of what constitutes invalid input
- Clarifying the distinction between
#[derive(Builder)]and#[builder]annotationsConsider adding this content before the code example:
# Fallible Builders With `bon`, you can write a builder that validates its inputs and returns a `Result`. It's possible to do this only via the function or associated method syntax. If you need to build a struct and do some validation, you won't be able to use the `#[derive(Builder)]` annotation on the struct for that. You'll *have to* define your logic in the associated constructor method (e.g. `new`). + +Input validation is crucial for ensuring data integrity and preventing invalid states. Common validation scenarios include: +- Ensuring string fields are not empty +- Validating numeric ranges +- Checking relationships between fields + +While the `#[derive(Builder)]` annotation is great for simple builders, the `#[builder]` attribute on methods provides more flexibility when validation is needed.
23-23: Improve error message formatting.The error message could be more readable by using format args instead of string interpolation.
- return Err(anyhow::anyhow!("Empty name is disallowed (user id: {id})")); + return Err(anyhow::anyhow!("Empty name is disallowed (user id: {})", id));
30-39: Add a successful usage example.The current example only shows the error case. Adding a successful case would provide a complete picture.
Consider adding:
// Successful case let user = User::builder() .id(42) .name("Alice".to_string()) .build() .expect("Valid user creation"); assert_eq!(user.name, "Alice"); assert_eq!(user.id, 42);
41-41: Make the feature request call to action more prominent.Consider adding a dedicated section header and more context about the feature request.
+## Future Improvements + +### Automatic Validation Attributes + If you have a use case for some convenience attributes to do automatic validations using the `#[derive(Builder)]` macro with the struct syntax, then add a 👍 reaction to [this Github issue](https://github.com/elastio/bon/issues/34). + +This feature is being considered for future versions of `bon`. Your feedback will help prioritize its development.website/v2/guide/documenting.md (4)
7-26: Enhance the code example for completeness.While the example effectively demonstrates documentation placement, consider these improvements for better clarity:
- Add a complete builder pattern usage example showing method chaining
- Include an example for the
ageparameter- Document the return value with
#[must_use]attributeHere's the suggested enhancement:
/// Function that returns a greeting special-tailored for a given person +/// +/// # Returns +/// A greeting message containing the person's name and age. #[builder] +#[must_use] fn greet( /// Name of the person to greet. /// /// **Example:** /// ``` - /// greet().name("John"); + /// greet().name("John").age(25).build(); /// ``` name: &str, /// Age expressed in full years passed since the birth date. + /// + /// **Example:** + /// ``` + /// greet().age(25).name("John").build(); + /// ``` age: u32 ) -> String { format!("Hello {name} with age {age}!") }
28-32: Consider adding information about edge cases.The technical explanation is clear, but it would be helpful to mention any limitations or edge cases. For example, what happens with doc attributes other than
#[doc = ...]?Consider adding:
This works because Rust compiler checks for invalid placement of `#[doc = ...]` attributes only after the macro expansion stage. `#[builder]` makes sure to remove the docs from the function's arguments in the expanded code, and instead moves them to the docs on setter methods. + +Note that this only applies to standard documentation comments. Other doc attributes like `#[doc(hidden)]` are not supported on function arguments.
34-34: Add an example for struct documentation.The explanation would be clearer with a concrete example showing how documentation is copied from struct fields to setter methods.
Consider adding:
When `#[derive(Builder)]` is placed on top of a struct, then documentation on the struct fields will be copied to the docs on the setter methods. + +**Example:** + +```rust +#[derive(Builder)] +struct Person { + /// Person's full name. + /// + /// This documentation will be copied to the `name()` setter method. + name: String, + + /// Person's age in years. + /// + /// This documentation will be copied to the `age()` setter method. + age: u32, +} +```
36-38: Add an example of recommended documentation for positional members.The explanation would be more helpful with an example showing how to properly document positional members at the struct/function level.
Consider adding:
Documentation comments are allowed on [positional members](./positional-members). However, since there are no separate setter methods generated for them, the docs on these members will not be copied anywhere, and thus they won't appear in `rustdoc`. Instead, it's recommended to write documentation for these members on the top level of the struct or function. + +**Example:** + +```rust +/// Represents a point in 2D space. +/// +/// # Fields +/// * First positional member: X coordinate +/// * Second positional member: Y coordinate +#[derive(Builder)] +struct Point(f64, f64); +```website/v2/guide/internal/contributing.md (3)
8-10: Fix grammar and improve clarity.The sentence structure needs improvement, and there's a missing comma.
Apply this diff:
-Before you start working on a code contribution make sure it will be accepted. If your change introduces new behavior like a new macro attribute or some new syntax then you should probably [open an issue](https://github.com/elastio/bon/issues) that describes your change first. We'll let you know if we'll accept a pull request for the change suggested in that issue. +Before you start working on a code contribution, make sure it will be accepted. If your change introduces new behavior (such as a new macro attribute or syntax), you should probably [open an issue](https://github.com/elastio/bon/issues) first describing your proposed change. We'll let you know if we'll accept a pull request for the suggested change.🧰 Tools
🪛 LanguageTool
[uncategorized] ~8-~8: Possible missing comma found.
Context: ...!** Before you start working on a code contribution make sure it will be accepted. If your ...(AI_HYDRA_LEO_MISSING_COMMA)
18-21: Consider enhancing testing instructions.While the current instructions are good, they could be more comprehensive.
Consider adding:
- How to run specific test suites (e.g.,
cargo test -p bon)- How to run only UI tests
- How to update UI test expectations
- How to add new UI test cases
Would you like me to help draft these additional instructions?
37-37: Improve phrasing in release description.The phrase "moment in time" is redundant.
Apply this diff:
-We'll release your change soon after it lands in `master`, or later as part of a bigger release. It depends on the kind of change you made and the state of the code in `master` at that specific moment in time. Anyway, we'll tell you in PR comments when we plan to release it. +We'll release your change soon after it lands in `master`, or later as part of a bigger release. It depends on the kind of change you made and the current state of the code in `master`. We'll communicate the planned release timeline in PR comments.🧰 Tools
🪛 LanguageTool
[style] ~37-~37: This phrase is redundant. Consider writing “moment” or “time”.
Context: ...f the code inmasterat that specific moment in time. Anyway, we'll tell you in PR comments ...(MOMENT_IN_TIME)
website/v2/guide/optional-members.md (4)
1-36: LGTM! Clear and accurate explanation of optional members.The explanation and example effectively demonstrate how
Option<T>members work in the builder pattern. The compatibility tip is particularly valuable for users considering API changes.Consider adding a comma in line 5: "If they aren't invoked, then
Nonewill be used as the default."
37-56: LGTM! Comprehensive examples of both simple and advanced usage.The examples effectively demonstrate when to use direct value setters versus
maybe_variants.Consider adding a comma in line 45: "If you already have an
Optionvariable somewhere, or you need to dynamically decide if the value should beSomeorNone..."🧰 Tools
🪛 LanguageTool
[uncategorized] ~45-~45: Use a comma before ‘or’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...eady have anOptionvariable somewhere or you need to dynamically decide if the v...(COMMA_COMPOUND_SENTENCE)
57-102: LGTM! Well-documented default attribute usage with verification.The examples effectively demonstrate both
Defaulttrait usage and custom default values, with assertions that help verify the expected behavior.Consider adding a comma in line 59: "To make a member of non-
Optiontype optional, you may use the attribute..."🧰 Tools
🪛 LanguageTool
[uncategorized] ~59-~59: Possible missing comma found.
Context: ... To make a member of non-Optiontype optional you may use the attribute [`#[builder(d...(AI_HYDRA_LEO_MISSING_COMMA)
103-111: LGTM! Good navigation and terminology clarification.The conclusion effectively guides readers to related content, and the glossary terms help maintain consistent terminology throughout the documentation.
Consider adding a comma in line 106: "Now that you know how optional members work, you can check out..."
🧰 Tools
🪛 LanguageTool
[uncategorized] ~106-~106: A comma might be missing here.
Context: ... Now that you know how optional members work you can check out the ["Conditional bui...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
website/v2/guide/benchmarks.md (5)
3-11: Minor language improvements suggested for better readability.Consider these refinements to enhance clarity and professionalism:
- Line 4: Add a comma after "In many cases"
- Line 7-8: Remove the redundant "TIP" as it's already in the ::: tip directive
- Line 9: Consider rephrasing "Feel free to" to something more formal, such as "Please"
-In many cases `rustc` generates the same assembly code +In many cases, `rustc` generates the same assembly code -::: tip TIP +::: tip -Feel free to [open an issue] +Please [open an issue]🧰 Tools
🪛 LanguageTool
[formatting] ~4-~4: Insert a comma after ‘cases’: “In many cases,”?
Context: ...functions annotated with#[builder]. In many casesrustcgenerates the same assembly cod...(IN_MOST_CASES_COMMA)
[duplication] ~7-~7: Possible typo: you repeated a word
Context: ...rmance differences are negligible. ::: tip TIP Don't take these microbenchmarks for g...(ENGLISH_WORD_REPEAT_RULE)
[style] ~9-~9: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ...in your application in real conditions. Feel free to [open an issue](https://github.com/elas...(FEEL_FREE_TO_STYLE_ME)
15-22: Consider explaining assembly output differences.The table includes different types of assembly output comparisons ("Equal", "Ordering diff", "Instructions diff"), but their significance isn't explained. Consider adding a brief explanation of what these differences mean and their practical implications.
Would you like me to draft an explanation section that clarifies these assembly output differences?
24-33: Consider adding explanations for performance metrics.The high-precision statistics table provides valuable data but could benefit from brief explanations of:
- What L1, L2, and RAM accesses represent
- Why these metrics are important
- How to interpret these numbers in the context of performance
Would you like me to draft explanatory text for these performance metrics?
37-37: Consider adding Rust compiler version information.While the optimization levels are specified, adding the Rust compiler version used for these benchmarks would provide important context, as performance characteristics might vary between compiler versions.
-The code was compiled with `opt-level = 3` and `debug = 0`. +The code was compiled with `rustc 1.x.y`, using `opt-level = 3` and `debug = 0`.
47-49: Consider expanding the references section.To make the benchmarks more reproducible and transparent, consider adding:
- Instructions for running the benchmarks locally
- A link to the specific commit or version used for these results
- Any additional tools or setup required to reproduce these results
Would you like me to draft this additional documentation?
website/v2/guide/patterns/shared-configuration.md (5)
11-41: Consider enhancing the code example for better clarity.While the example effectively demonstrates the configuration duplication, consider:
- Adding a minimal but realistic struct field instead of
/**/to make the example more concrete- Expanding the tip to explicitly mention that
Intoconversions allow automatic type conversion (e.g.,&strtoString)#[derive(Builder)] #[builder( on(String, into), on(Box<_>, into), finish_fn = finish, )] -struct MyLovelyStruct1 { /**/ } +struct MyLovelyStruct1 { + name: String, // Will accept both String and &str + data: Box<i32>, // Will accept both Box<i32> and i32 +}
65-70: Enhance the solution example with realistic fields.Similar to the problem statement, consider adding minimal but realistic struct fields instead of
/**/to make the example more concrete.#[apply(derive_builder!)] -struct MyLovelyStruct1 { /**/ } +struct MyLovelyStruct1 { + name: String, + data: Box<i32>, +}
72-72: Consider providing more specific performance context.The statement about compilation performance could be more specific. Consider adding approximate compilation times or percentage differences to strengthen the claim.
🧰 Tools
🪛 LanguageTool
[style] ~72-~72: The phrase ‘a lot of’ might be wordy and overused. Consider using an alternative.
Context: ...*/ } ``` Use this approach if you have a lot of structs in your crate that need a build...(A_LOT_OF)
103-103: Consider standardizing the GitHub issue link format.The GitHub issue link format
#elastio/bon#144is non-standard. Consider using the full URL format for better compatibility across different Markdown renderers.-[#elastio/bon#144](https://github.com/elastio/bon/issues/144) +[elastio/bon#144](https://github.com/elastio/bon/issues/144)🧰 Tools
🪛 LanguageTool
[style] ~103-~103: Try using a synonym here to strengthen your wording.
Context: ... a solution for this, and maybe leave a comment about your particular use case where yo...(COMMENT_REMARK)
46-46: Consider these writing style improvements:
- Add a comma: "To overcome this problem, we can utilize..."
- Replace "a lot of" with "many" for more concise writing
- Remove redundant "of" in "inside of the impl block"
Also applies to: 72-72, 101-101
🧰 Tools
🪛 LanguageTool
[typographical] ~46-~46: It seems that a comma is missing.
Context: ...Solution ### Structs To overcome this problem we can utilize the [`macro_rules_attrib...(IN_ORDER_TO_VB_COMMA)
website/v2/guide/patterns/conditional-building.md (2)
1-6: Add comma for better readability.Add a comma after "below 🐱" to improve the flow of the sentence.
-On this page, we'll review a case when you have multiple branches in your code that need to set different values for different builder members. Since the builders generated by `bon` use the type-state pattern and the setters consume `self`, it is a bit more complicated for conditional code to use them. But, not until you know the patterns described below 🐱. So let's learn how to write better conditional code 📚. +On this page, we'll review a case when you have multiple branches in your code that need to set different values for different builder members. Since the builders generated by `bon` use the type-state pattern and the setters consume `self`, it is a bit more complicated for conditional code to use them. But, not until you know the patterns described below 🐱, so let's learn how to write better conditional code 📚.🧰 Tools
🪛 LanguageTool
[uncategorized] ~3-~3: Possible missing comma found.
Context: ...u know the patterns described below 🐱. So let's learn how to write better conditi...(AI_HYDRA_LEO_MISSING_COMMA)
115-140: Consider adding a warning about tuple size impact on readability.While the tuple pattern is shown with two members, it might be helpful to specify a recommended maximum number of tuple members before switching to separate variables.
However, when the number of members in the conditional logic grows, such an `if` with tuples becomes hard to read. In such a case, consider defining variables outside of the `if` or using the [shared partial builder](#shared-partial-builder) pattern instead. + +As a rule of thumb, consider using separate variables when dealing with more than 2-3 members to maintain code readability.🧰 Tools
🪛 LanguageTool
[style] ~123-~123: This phrase is redundant. Consider using “outside”.
Context: ...uch a case, consider defining variables outside of theifor using the [shared partial b...(OUTSIDE_OF)
website/v2/guide/limitations.md (5)
9-9: Improve grammar in the error message description.The sentence structure can be improved for better clarity.
-If there are any, then a compile error suggesting to use the full type name will be generated. +If there are any, then a compile error will be generated suggesting the use of the full type name.🧰 Tools
🪛 LanguageTool
[grammar] ~9-~9: The verb ‘suggesting’ is used with the gerund form.
Context: ... If there are any, then a compile error suggesting to use the full type name will be generated. ...(ADMIT_ENJOY_VB)
7-12: Consider mentioning potential future automation.The documentation clearly explains the limitation with
Selfreferences. Consider mentioning if there are plans to automatically replaceSelfwith the actual type name in a future version, as this could be a quality-of-life improvement.🧰 Tools
🪛 LanguageTool
[grammar] ~9-~9: The verb ‘suggesting’ is used with the gerund form.
Context: ... If there are any, then a compile error suggesting to use the full type name will be generated. ...(ADMIT_ENJOY_VB)
79-90: Consider showing the non-working version first.To make the documentation more instructive, consider showing the non-working version with destructuring patterns first, followed by the working solution. This would help readers better understand what to avoid.
// Non-working example: #[builder] fn example(((x, y)): (u32, u32)) {} // This won't work! // Working solution: #[builder] fn example(point: (u32, u32)) { let (x, y) = point; }
94-95: Consider adding rustfmt version information.Since this is a formatting issue that might be fixed in future versions of rustfmt, consider adding the affected rustfmt version range to help readers understand if this limitation still applies to their setup.
139-144: Consider adding a minimal example.To better illustrate the const function limitation, consider adding a minimal example showing:
- A const function with the builder attribute
- The generated non-const builder methods
// Example to consider adding: #[builder] const fn example(x: u32) -> u32 { x + 1 } // Generated builder (showing why it can't be const): impl ExampleBuilder { fn x(self, value: u32) -> ExampleBuilderDone { // Uses non-const Into::into ExampleBuilderDone { x: value.into() } } }website/v2/config.mts (1)
1-162: Consider adding version selection UI component.The modular approach to version-specific documentation is good. Consider adding a version selector component in the navigation to help users switch between different versions of the documentation easily.
Some suggestions:
- Add a dropdown in the nav bar for version selection
- Consider adding version badges to indicate the latest stable version
- Add a banner for outdated versions directing users to the latest docs
website/v2/guide/positional-members.md (5)
10-10: Minor grammatical improvement needed.Consider adding a comma after "that" to improve readability:
"To do that, we can use the#[builder(start_fn)]attribute."🧰 Tools
🪛 LanguageTool
[formatting] ~10-~10: Consider inserting a comma after ‘that’.
Context: ...em in a single starting function call. To do that we can use the#[builder(start_fn)]a...(TO_VERB_COMMA)
47-53: Consider adding a note about parameter ordering.The documentation would benefit from explicitly mentioning that the order of positional parameters in the generated method signature matches the order of members with
#[builder(start_fn)]in the struct definition. This is important for API users to understand how the parameters map to struct fields.
87-96: Document error handling behavior.Consider adding information about what happens if a user forgets to call the
claimmethod or provides invalid parameters. This would help users understand the runtime behavior and error handling of the builder pattern.
127-130: Add generated method signature for clarity.Consider adding a code block showing the generated method signature for the
claimmethod withintoconversions, similar to how thewith_coordinatessignature was shown earlier. This would help users understand the exact types accepted by the method.Example:
impl TreasureBuilder { fn claim(self, first: impl Into<String>, last: impl Into<String>) -> Treasure { /**/ } }
144-144: Add an example demonstrating the limitation.Consider adding a small code example showing why optional positional members are problematic. This would make the warning more concrete and help users understand the practical implications.
Example:
#[derive(Builder)] #[builder(start_fn = new)] struct Config { #[builder(start_fn)] name: Option<String>, // This is problematic because the value must always be provided } // Users must always provide a value, even if they want None let config = Config::new(None); // Required, can't omit the parameterwebsite/v2/guide/compatibility.md (2)
13-26: Consider adding error handling to the example.While the example demonstrates the basic usage, it would be more realistic to include error handling for the password parameter.
Consider updating the example to show error handling:
#[builder] fn get_page(password: &str) -> String { + // Demonstrate input validation + if password.is_empty() { + return String::from("Access denied: Empty password"); + } format!("Secret knowledge") }
83-83: Improve conciseness of the explanation.The phrase "for the time being" can be replaced with "temporarily" for better clarity.
-You may add `_` prefix to the member name to mark it as unused for the time being. +You may add `_` prefix to the member name to mark it as temporarily unused.🧰 Tools
🪛 LanguageTool
[style] ~83-~83: This phrasing can be wordy. For improved clarity, try opting for something more concise.
Context: ...to the member name to mark it as unused for the time being. The builder API won't change if you do...(FOR_THE_TIME_BEING)
website/v2/guide/alternatives.md (3)
7-7: Consider improving the introduction's clarity.Add a comma after "builder crates" to improve readability.
-There are several other existing alternative crates that generate builders. `bon` was designed with many lessons learned from them. +There are several other existing alternative crates that generate builders, and `bon` was designed with many lessons learned from them.🧰 Tools
🪛 LanguageTool
[uncategorized] ~7-~7: Possible missing comma found.
Context: ...re is a table that compares the builder crates with some additional explanations below...(AI_HYDRA_LEO_MISSING_COMMA)
11-28: LGTM! Consider using a table generator tool.The comparison table is well-structured and informative. To maintain consistency and ease future updates, consider using a markdown table generator tool.
🧰 Tools
🪛 Markdownlint
14-14: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
15-15: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
21-21: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
22-22: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
23-23: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
24-24: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
14-14: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
15-15: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
21-21: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
22-22: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
23-23: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
24-24: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
64-71: Consider enhancing the macros documentation.While the macros' basic usage is clear, it would be helpful to:
- Add examples showing the
Intoconversion behavior for each macro type- Document any performance implications of using these macros compared to direct collection initialization
website/guide/overview.md (1)
Line range hint
272-297: Consider accessibility and styling improvements.While the social links implementation is functional, consider these enhancements:
- Add aria-labels to improve accessibility for screen readers
- Move inline styles to a CSS file for better maintainability
- Replace the "nobr" class with a more semantic solution
Here's how you could enhance the implementation:
<div style="display: flex; align-items: center"> <VPSocialLink icon="discord" + aria-label="Join our Discord server" link="https://discord.gg/QcBYSamw4c" /> <a href="https://discord.gg/QcBYSamw4c">Discord</a> </div>And in your CSS file:
.social-link-container { display: flex; align-items: center; } .no-wrap { white-space: nowrap; }website/v2/guide/overview.md (3)
57-57: Add missing commas for better readability.Several sentences would benefit from additional commas:
- Line 57: "For this to work, you need to add..."
- Line 114: "To follow the usual Rust builder naming conventions,
bontreats..."- Line 122: "For any other methods not called
newand for any free function, the naming..."- Line 154: "on a struct, generates builder API..."
Also applies to: 114-114, 122-122, 154-154
🧰 Tools
🪛 LanguageTool
[uncategorized] ~57-~57: Possible missing comma found.
Context: ...der for associated methods. For this to work you need to add a#[bon]macro on top...(AI_HYDRA_LEO_MISSING_COMMA)
99-99: Simplify redundant phrases.Replace "inside of" with "inside" in several locations for more concise writing:
- Line 99: "macro inside the
implblock"- Line 101: "macro inside the
implblock"- Line 114: "inside the impl block"
- Line 163: "inside the builder"
Also applies to: 101-101, 114-114, 163-163
🧰 Tools
🪛 LanguageTool
[style] ~99-~99: This phrase is redundant. Consider using “inside”.
Context: ...of. For example, the#[builder]macro inside of theimplblock can't see the `impl Co...(OUTSIDE_OF)
259-259: Consider more formal language alternatives.Some phrases could be more professional:
- Line 259: Instead of "like the idea", consider "find value in" or "appreciate"
- Line 303: Instead of "awesome crates", consider "excellent crates" or "notable crates"
Also applies to: 303-303
🧰 Tools
🪛 LanguageTool
[style] ~259-~259: “Like the idea” can sound informal and uncommitted. To express your support in a professional manner, consider using a different phrase.
Context: ... (!). ## What's next? ::: tip If you like the idea of this crate and want to say "thank you" ...(LIKE_THE_IDEA)
website/v2/guide/patterns/into-conversions-in-depth.md (5)
4-5: Remove extra blank line.There's an unnecessary double blank line after the frontmatter.
--- outline: deep --- - # `Into` Conversions In-Depth
183-184: Enhance the performance explanation with concrete metrics.Consider adding a benchmark example that demonstrates the performance impact of implicit allocations, making the warning more tangible for readers.
// Add a benchmark example like this: use criterion::{black_box, criterion_group, criterion_main, Criterion}; fn benchmark_direct_vs_into(c: &mut Criterion) { let json = String::from("...large JSON..."); c.bench_function("direct", |b| b.iter(|| { process_heavy_json().data(black_box(json.clone())).call() })); c.bench_function("into_ref", |b| b.iter(|| { process_heavy_json().data(black_box(&json)).call() })); }🧰 Tools
🪛 LanguageTool
[uncategorized] ~183-~183: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...n pose a bottleneck for your application and you need to see every place in code whe...(COMMA_COMPOUND_SENTENCE)
229-230: Clarify the numeric literal type inference explanation.The explanation about numeric literal type inference could be more precise. Consider mentioning that this is part of Rust's type inference rules where integer literals default to
i32only when the type cannot be inferred from context.🧰 Tools
🪛 LanguageTool
[grammar] ~229-~229: If ‘type’ is a classification term, ‘a’ is not necessary. Use “type of”. (The phrases ‘kind of’ and ‘sort of’ are informal if they mean ‘to some extent’.)
Context: ...10. When the compiler can't infer the type of a numeric literal it falls back to assign...(KIND_OF_A)
[uncategorized] ~229-~229: Possible missing comma found.
Context: ...piler can't infer the type of a numeric literal it falls back to assigning the type `i3...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~229-~229: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... for an integer literal andf64for a floating point literal. In this casei32is inferred...(EN_COMPOUND_ADJECTIVE_INTERNAL)
[formatting] ~229-~229: Consider inserting a comma after an introductory phrase for better readability.
Context: ...andf64for a floating point literal. In this casei32is inferred, which isn't converti...(IN_THAT_CASE_COMMA)
252-255: Improve the type inference explanation.The explanation about type inference could be more technical. Consider mentioning that this is due to Rust's bidirectional type inference system, where type information flows from both the definition site and usage site.
🧰 Tools
🪛 LanguageTool
[style] ~252-~252: As an alternative to the over-used intensifier ‘really’, consider replacing this phrase.
Context: ...ects a parameter of typeIpAddr. It's a really simple exercise for the compiler in this case ...(EN_WEAK_ADJECTIVE)
377-379: Consider moving abbreviations to the top.The abbreviations section might be more useful at the beginning of the document, helping readers understand terminology from the start.
website/v2/reference/builder.md (2)
7-10: Consider adding examples for each syntax form in the introduction.While the introduction clearly states the three syntax forms and two attribute groups, it would be helpful to briefly show what each syntax form looks like before diving into the detailed examples.
You can generate a builder using three different kinds of syntax (struct, free function, associated method). They all share two common groups of attributes. + +```rust +// Struct syntax +#[derive(Builder)] +struct Example { /* ... */ } + +// Free function syntax +#[builder] +fn example() { /* ... */ } + +// Associated method syntax +#[bon] +impl Example { + #[builder] + fn example() { /* ... */ } +} +``` + - [Top-level attributes](#top-level-attributes) - placed on a `struct` or `fn` declaration. - [Member attributes](#member-attributes) - placed on a `struct` field or `fn` argument.
167-167: Polish the documentation text.Consider these language and style improvements:
- Add a comma before 'and' in compound sentences (line 167): "...is not stable, and it may change..."
- Replace redundant phrases:
- "inside of" → "inside" (lines 301, 663)
- "in regard to" → "regarding" (lines 963, 1303)
- Use "who" instead of "that" when referring to members (lines 766, 1173): "members who are declared earlier"
Also applies to: 301-302, 663-663, 766-766, 963-963, 1173-1173, 1303-1303
🧰 Tools
🪛 LanguageTool
[uncategorized] ~167-~167: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...bug` output of the builder is not stable and it may change between the patch version...(COMMA_COMPOUND_SENTENCE)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
website/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (22)
- website/.vitepress/config.mts (3 hunks)
- website/.vitepress/theme/utils/versioning.ts (1 hunks)
- website/guide/overview.md (2 hunks)
- website/package.json (2 hunks)
- website/v2/config.mts (1 hunks)
- website/v2/guide/alternatives.md (1 hunks)
- website/v2/guide/benchmarks.md (1 hunks)
- website/v2/guide/compatibility.md (1 hunks)
- website/v2/guide/documenting.md (1 hunks)
- website/v2/guide/inspecting.md (1 hunks)
- website/v2/guide/internal/contributing.md (1 hunks)
- website/v2/guide/limitations.md (1 hunks)
- website/v2/guide/optional-members.md (1 hunks)
- website/v2/guide/overview.md (1 hunks)
- website/v2/guide/patterns/conditional-building.md (1 hunks)
- website/v2/guide/patterns/fallible-builders.md (1 hunks)
- website/v2/guide/patterns/into-conversions-in-depth.md (1 hunks)
- website/v2/guide/patterns/shared-configuration.md (1 hunks)
- website/v2/guide/positional-members.md (1 hunks)
- website/v2/guide/troubleshooting.md (1 hunks)
- website/v2/reference/bon.md (1 hunks)
- website/v2/reference/builder.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
website/v2/guide/alternatives.md
[uncategorized] ~7-~7: Possible missing comma found.
Context: ...re is a table that compares the builder crates with some additional explanations below...(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~62-~62: If ‘type’ is a classification term, ‘a’ is not necessary. Use “type of”. (The phrases ‘kind of’ and ‘sort of’ are informal if they mean ‘to some extent’.)
Context: ...ckwards compatibility when changing the type of a member fromTorOption<T>to `Coll...(KIND_OF_A)
website/v2/guide/benchmarks.md
[formatting] ~4-~4: Insert a comma after ‘cases’: “In many cases,”?
Context: ...functions annotated with#[builder]. In many casesrustcgenerates the same assembly cod...(IN_MOST_CASES_COMMA)
[duplication] ~7-~7: Possible typo: you repeated a word
Context: ...rmance differences are negligible. ::: tip TIP Don't take these microbenchmarks for g...(ENGLISH_WORD_REPEAT_RULE)
[style] ~9-~9: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ...in your application in real conditions. Feel free to [open an issue](https://github.com/elas...(FEEL_FREE_TO_STYLE_ME)
website/v2/guide/compatibility.md
[style] ~83-~83: This phrasing can be wordy. For improved clarity, try opting for something more concise.
Context: ...to the member name to mark it as unused for the time being. The builder API won't change if you do...(FOR_THE_TIME_BEING)
website/v2/guide/inspecting.md
[uncategorized] ~3-~3: Possible missing comma found.
Context: ...values set in the builder for debugging purposes you can leverage the [`#[builder(derive...(AI_HYDRA_LEO_MISSING_COMMA)
website/v2/guide/internal/contributing.md
[uncategorized] ~8-~8: Possible missing comma found.
Context: ...!** Before you start working on a code contribution make sure it will be accepted. If your ...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~37-~37: This phrase is redundant. Consider writing “moment” or “time”.
Context: ...f the code inmasterat that specific moment in time. Anyway, we'll tell you in PR comments ...(MOMENT_IN_TIME)
website/v2/guide/limitations.md
[grammar] ~9-~9: The verb ‘suggesting’ is used with the gerund form.
Context: ... If there are any, then a compile error suggesting to use the full type name will be generated. ...(ADMIT_ENJOY_VB)
[style] ~48-~48: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...er]` macro sees in the example above is just this: ```rust ignore fn example(value:...(REP_BE_JUST)
website/v2/guide/optional-members.md
[uncategorized] ~45-~45: Use a comma before ‘or’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...eady have anOptionvariable somewhere or you need to dynamically decide if the v...(COMMA_COMPOUND_SENTENCE)
[uncategorized] ~59-~59: Possible missing comma found.
Context: ... To make a member of non-Optiontype optional you may use the attribute [`#[builder(d...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~106-~106: A comma might be missing here.
Context: ... Now that you know how optional members work you can check out the ["Conditional bui...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
website/v2/guide/overview.md
[uncategorized] ~57-~57: Possible missing comma found.
Context: ...der for associated methods. For this to work you need to add a#[bon]macro on top...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~99-~99: This phrase is redundant. Consider using “inside”.
Context: ...of. For example, the#[builder]macro inside of theimplblock can't see the `impl Co...(OUTSIDE_OF)
[style] ~101-~101: This phrase is redundant. Consider using “inside”.
Context: ...evel of nesting. The#[builder]macro inside of theimplblock can't just break out o...(OUTSIDE_OF)
[uncategorized] ~114-~114: Possible missing comma found.
Context: ...To follow the usual Rust builder naming conventionsbontreats the method namednewins...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~114-~114: This phrase is redundant. Consider using “inside”.
Context: ...onsbontreats the method namednewinside of the impl block specially. It generates ...(OUTSIDE_OF)
[uncategorized] ~122-~122: Possible missing comma found.
Context: ...thods not callednewand for any free function the naming is a bit different: | Start...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~154-~154: Possible missing comma found.
Context: ...``` ::: tip#[derive(Builder)]on a struct generates builder API that is fully com...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~163-~163: This phrase is redundant. Consider using “inside”.
Context: ...o potential panics andunwrap()calls inside of the builder. ##Option<T>values are...(OUTSIDE_OF)
[style] ~259-~259: “Like the idea” can sound informal and uncommitted. To express your support in a professional manner, consider using a different phrase.
Context: ... (!). ## What's next? ::: tip If you like the idea of this crate and want to say "thank you" ...(LIKE_THE_IDEA)
[style] ~303-~303: Consider using a more formal and expressive alternative to ‘awesome’.
Context: ...is project was heavily inspired by such awesome crates as [buildstructor](https://doc...(AWESOME)
website/v2/guide/patterns/conditional-building.md
[uncategorized] ~3-~3: Possible missing comma found.
Context: ...u know the patterns described below 🐱. So let's learn how to write better conditi...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~43-~43: Possible missing comma found.
Context: ... the branches of conditional code. This way every branch returns the value of the s...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~51-~51: This phrase is redundant. Consider using “inside”.
Context: ...r "context loss". The part of the code inside of the conditional branches has more conte...(OUTSIDE_OF)
[style] ~51-~51: This phrase is redundant. Consider using “inside”.
Context: ...han the code that comes after. The code inside of the conditional block has a strongly ty...(OUTSIDE_OF)
[style] ~123-~123: This phrase is redundant. Consider using “outside”.
Context: ...uch a case, consider defining variables outside of theifor using the [shared partial b...(OUTSIDE_OF)
website/v2/guide/patterns/into-conversions-in-depth.md
[style] ~12-~12: The phrase ‘pretty much’ can be informal. To strengthen your writing, consider removing it or replacing it with an adverb.
Context: ...fore you proceed. Reading their docs is pretty much enough. For example, you should know th...(PRETTY_MUCH)
[style] ~31-~31: Consider removing “of” to be more concise
Context: ...conversions usually make sense only if all of the following are true (AND): ::: tip The...(ALL_OF_THE)
[style] ~36-~36: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...t performance-sensitive. 2. The builder is going to be used with literal values a lot or re...(GOING_TO_WILL)
[uncategorized] ~36-~36: Possible missing comma found.
Context: ... going to be used with literal values a lot or require wrapping the values. ::: ...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~183-~183: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...n pose a bottleneck for your application and you need to see every place in code whe...(COMMA_COMPOUND_SENTENCE)
[grammar] ~229-~229: If ‘type’ is a classification term, ‘a’ is not necessary. Use “type of”. (The phrases ‘kind of’ and ‘sort of’ are informal if they mean ‘to some extent’.)
Context: ...10. When the compiler can't infer the type of a numeric literal it falls back to assign...(KIND_OF_A)
[uncategorized] ~229-~229: Possible missing comma found.
Context: ...piler can't infer the type of a numeric literal it falls back to assigning the type `i3...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~229-~229: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... for an integer literal andf64for a floating point literal. In this casei32is inferred...(EN_COMPOUND_ADJECTIVE_INTERNAL)
[formatting] ~229-~229: Consider inserting a comma after an introductory phrase for better readability.
Context: ...andf64for a floating point literal. In this casei32is inferred, which isn't converti...(IN_THAT_CASE_COMMA)
[uncategorized] ~235-~235: Possible missing comma found.
Context: ...r needs to infer that generic type from usage unless it's specified explicitly. A cla...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~252-~252: As an alternative to the over-used intensifier ‘really’, consider replacing this phrase.
Context: ...ects a parameter of typeIpAddr. It's a really simple exercise for the compiler in this case ...(EN_WEAK_ADJECTIVE)
[uncategorized] ~294-~294: A comma may be missing after the conjunctive/linking adverb ‘Thus’.
Context: ...compiler a single type that it accepts. Thus the compiler can't decide which type to...(SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA)
[formatting] ~294-~294: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ip_addrvariable in the original code, because there can be many that make sense. I....(COMMA_BEFORE_BECAUSE)
[grammar] ~334-~334: The verb form ‘code’ does not seem to be suitable in this context.
Context: ... .build();When we compile this code we get the following error:log .ma...(THIS_VBP_DT)
[typographical] ~334-~334: Consider inserting a comma for improved readability.
Context: ....build();When we compile this code we get the following error:log .maybe...(INITIAL_ADVP_COMMA)
[style] ~342-~342: This phrase is redundant. Consider using “inside”.
Context: ...e many potential candidates for the_inside of theOption<_>. This is because the si...(OUTSIDE_OF)
[uncategorized] ~349-~349: Possible missing comma found.
Context: ...!code ++] ``` Before we enabledIntoconversions the signature provided a hint for the c...(AI_HYDRA_LEO_MISSING_COMMA)
[formatting] ~353-~353: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...de which one you meant. And this matters, becauseOption<&str>andOption<String>are...(COMMA_BEFORE_BECAUSE)
[uncategorized] ~355-~355: Possible missing comma found.
Context: ...n they areNone. To work around this problem the caller would need to explicitly spe...(AI_HYDRA_LEO_MISSING_COMMA)
website/v2/guide/patterns/shared-configuration.md
[typographical] ~46-~46: It seems that a comma is missing.
Context: ...Solution ### Structs To overcome this problem we can utilize the [`macro_rules_attrib...(IN_ORDER_TO_VB_COMMA)
[style] ~72-~72: The phrase ‘a lot of’ might be wordy and overused. Consider using an alternative.
Context: ...*/ } ``` Use this approach if you have a lot of structs in your crate that need a build...(A_LOT_OF)
[style] ~101-~101: This phrase is redundant. Consider using “inside”.
Context: ... first before the#[apply(...)]macro inside of the impl block, so#[bon]doesn't see...(OUTSIDE_OF)
[style] ~103-~103: Try using a synonym here to strengthen your wording.
Context: ... a solution for this, and maybe leave a comment about your particular use case where yo...(COMMENT_REMARK)
website/v2/guide/positional-members.md
[formatting] ~10-~10: Consider inserting a comma after ‘that’.
Context: ...em in a single starting function call. To do that we can use the#[builder(start_fn)]a...(TO_VERB_COMMA)
[uncategorized] ~56-~56: Possible missing comma found.
Context: ... { /**/ } } ``` ## Finishing function Now let's say we need to know the person wh...(AI_HYDRA_LEO_MISSING_COMMA)
[typographical] ~134-~134: After the expression ‘for example’ a comma is usually used.
Context: ...heOptiontype for such members. For example#[builder(into)]on a regular (named)...(COMMA_FOR_EXAMPLE)
[style] ~138-~138: Consider using a different adverb to strengthen your wording.
Context: .... For positional members, the story is completely different because there are no separate...(COMPLETELY_ENTIRELY)
[uncategorized] ~140-~140: Possible missing comma found.
Context: ... matches theOption<T>fully. So, for exampleon(String, into)will not match the p...(AI_HYDRA_LEO_MISSING_COMMA)
website/v2/guide/troubleshooting.md
[style] ~11-~11: This phrase is redundant. Consider using “inside”.
Context: ...ormative because it points to some code inside of the macro that you don't see. In this ...(OUTSIDE_OF)
[uncategorized] ~13-~13: Possible missing comma found.
Context: ...-recursively). It works for any kind of macro including attribute macros. Then copy ...(AI_HYDRA_LEO_MISSING_COMMA)
website/v2/reference/bon.md
[style] ~5-~5: This phrase is redundant. Consider using “inside”.
Context: ...uilder] macros on top of the functions inside of theimpl` block. You'll get compile er...(OUTSIDE_OF)
[grammar] ~8-~8: The verb “see” needs to be in the to-infinitive form.
Context: ...e of this macro and the reason why it's needed see this paragraph in [the overview](../gui...(MISSING_TO_BEFORE_A_VERB)
website/v2/reference/builder.md
[uncategorized] ~167-~167: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...bug` output of the builder is not stable and it may change between the patch version...(COMMA_COMPOUND_SENTENCE)
[style] ~301-~301: This phrase is redundant. Consider using “inside”.
Context: ...e the builder. That function is invoked inside of the builder'scall()orbuild()met...(OUTSIDE_OF)
[typographical] ~302-~302: Consider adding a comma after ‘Usually’ for more clarity.
Context: ...uilder'scall()orbuild()method. Usually you'd want the underlying positional fu...(RB_LY_COMMA)
[style] ~663-~663: This phrase is redundant. Consider using “inside”.
Context: ...e default value will be lazily computed inside of the finishing function (i...(OUTSIDE_OF)
[style] ~766-~766: Consider using “who” when you are referring to people instead of objects.
Context: ...eclaration. It means only those members that are declared earlier (higher) in the co...(THAT_WHO)
[style] ~963-~963: ‘In regard to’ might be wordy. Consider using a more concise alternative.
Context: ...rently from the regular (named) members in regard to theOptiontype. TheOptiontype gi...(REGARD_TO)
[style] ~1173-~1173: Consider using “who” when you are referring to people instead of objects.
Context: ...eclaration. It means only those members that are declared earlier (higher) in the co...(THAT_WHO)
[style] ~1303-~1303: ‘In regard to’ might be wordy. Consider using a more concise alternative.
Context: ...rently from the regular (named) members in regard to theOptiontype. TheOptiontype gi...(REGARD_TO)
🪛 Markdownlint
website/v2/guide/alternatives.md
14-14: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
15-15: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
21-21: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
22-22: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
23-23: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
24-24: Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
Table pipe style(MD055, table-pipe-style)
14-14: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
15-15: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
21-21: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
22-22: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
23-23: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
24-24: Expected: 5; Actual: 4; Too few cells, row will be missing data
Table column count(MD056, table-column-count)
website/v2/reference/builder.md
663-663: null
Link fragments should be valid(MD051, link-fragments)
868-868: null
Link fragments should be valid(MD051, link-fragments)
874-874: null
Link fragments should be valid(MD051, link-fragments)
1216-1216: null
Link fragments should be valid(MD051, link-fragments)
🔇 Additional comments (33)
website/package.json (2)
11-11: LGTM! Minor version updates look safe.The updates to
@mdit/plugin-abbrandts-patternare patch/minor version bumps, which should maintain backward compatibility.Also applies to: 22-22
23-23: Verify compatibility with VitePress 1.4.1 and Vue 3.5.xThese are significant version updates that warrant careful testing:
- VitePress upgrade from 1.3.4 to 1.4.1 might introduce breaking changes
- Vue upgrade from 3.4.x to 3.5.x could affect components
Also applies to: 26-26
✅ Verification successful
VitePress and Vue updates are safe to proceed
The codebase appears to be a standard VitePress documentation site with a versioned structure (v1, v2). Based on the analysis:
- No Vue components (
.vuefiles) are present in the codebase- The site uses standard VitePress markdown-based documentation
- Multiple version directories suggest proper separation of documentation versions
- No custom Vue-specific syntax or complex VitePress configurations were found that could be affected by the updates
The version bumps (VitePress 1.4.1 and Vue 3.5.12) are safe to proceed with as this is a straightforward documentation site without custom Vue components or complex VitePress configurations that could be impacted by the updates.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential breaking changes in the documentation setup # Test 1: Look for Vue-specific syntax that might be affected echo "Checking for Vue-specific syntax in documentation..." rg -g '*.{md,vue}' '{{.*}}|@[a-zA-Z]|v-[a-zA-Z]' # Test 2: Check VitePress configuration for deprecated options echo "Checking VitePress configuration..." rg -g '.vitepress/config.*' 'markdown:|themeConfig:|vue:|vite:'Length of output: 564
Script:
#!/bin/bash # Let's try a different approach to check for Vue and VitePress usage # Check for Vue components and templates echo "Checking Vue components and templates..." rg -g "*.vue" "template|script|@|v-" # Look for VitePress config echo "Looking for VitePress config..." fd "config\.(ts|js)" .vitepress # If config exists, let's examine its content echo "Examining VitePress config content..." fd "config\.(ts|js)" .vitepress -x cat {} # Check for any migration guides or breaking changes mentioned in docs echo "Checking for migration notes..." rg -g "*.md" "migration|breaking|upgrade"Length of output: 6152
Script:
#!/bin/bash # Let's check the website directory structure and config # Find VitePress config in website directory echo "Looking for VitePress config in website directory..." fd "config\.(ts|js)" website # Check website directory structure echo "Checking website directory structure..." ls -R website/ # Look for Vue components in website directory echo "Looking for Vue components in website directory..." fd "\.vue$" website # Check package.json to see if this is a fresh VitePress setup echo "Examining website/package.json..." cat website/package.jsonLength of output: 3067
website/.vitepress/theme/utils/versioning.ts (1)
3-4: Consider keeping v2 as the latest version until v3 is stable.Setting
v3-rcas thelatestVersionmeans it will be shown by default to all users. Consider keeping v2 as the latest version until v3 is officially released to avoid exposing users to potentially unstable documentation by default.website/v2/guide/troubleshooting.md (1)
1-23: Documentation structure and content look great!The troubleshooting guide is well-structured with clear sections covering known limitations, macro debugging, and support channels. The instructions are clear and the examples are helpful.
🧰 Tools
🪛 LanguageTool
[style] ~11-~11: This phrase is redundant. Consider using “inside”.
Context: ...ormative because it points to some code inside of the macro that you don't see. In this ...(OUTSIDE_OF)
[uncategorized] ~13-~13: Possible missing comma found.
Context: ...-recursively). It works for any kind of macro including attribute macros. Then copy ...(AI_HYDRA_LEO_MISSING_COMMA)
website/v2/guide/inspecting.md (1)
7-31: LGTM! Well-structured code example.The code example effectively demonstrates:
- Debug trait derivation
- Both stderr and string formatting options
- Clear comments explaining each step
- Complete builder workflow
website/v2/guide/patterns/fallible-builders.md (1)
1-41: Verify documentation consistency.Let's ensure the terminology and concepts align with other documentation files.
✅ Verification successful
Documentation is consistent and well-integrated
The documentation for fallible builders is consistent with the rest of the codebase:
- It correctly explains the limitation that validation is only possible via function/method syntax, not with
#[derive(Builder)]- The terminology aligns with other documentation files, using consistent terms like "builder", "validation", and proper macro syntax
- The referenced GitHub issue (Support input validation in builders #34) exists and is correctly linked
- The pattern fits within the broader documentation structure, complementing other patterns like conditional building and shared configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistency in builder-related terminology across docs # Test: Look for other mentions of builders and validation echo "Checking for related concepts in other docs..." rg -l "builder|validation" website/v2/guide/ # Test: Verify the referenced GitHub issue exists echo "Verifying GitHub issue link..." gh issue view 34 --json title,stateLength of output: 811
Script:
#!/bin/bash # Let's check the content of related builder documentation for consistency # Check overview.md for builder terminology echo "=== Content of overview.md ===" rg -A 5 "builder" website/v2/guide/overview.md # Check other builder-related patterns echo -e "\n=== Content of conditional-building.md ===" cat website/v2/guide/patterns/conditional-building.md # Check limitations regarding builders echo -e "\n=== Content of limitations.md regarding builders ===" rg -A 5 "builder" website/v2/guide/limitations.md # Check if there are any contradicting validation patterns echo -e "\n=== Checking for validation patterns ===" rg "validation|validate" website/v2/guide/Length of output: 18790
website/v2/guide/internal/contributing.md (4)
1-3: LGTM! VitePress frontmatter is correctly configured.The
outline: deepsetting will generate a detailed table of contents for this page.
39-46: LGTM! License section is complete and accurate.The dual-licensing and contribution agreement are properly documented.
26-27:⚠️ Potential issueFix incorrect documentation path.
The path
website/docsappears to be incorrect, as this contributing guide itself is located inwebsite/v2/guide/internal.Let's verify the correct documentation path:
#!/bin/bash # Check the actual documentation structure fd -t d "docs|guide" website/
1-46: Verify documentation version placement.The PR title mentions preparing for v3, but this file is located in the v2 directory. Please confirm if this is intentional or if the file should be moved to a v3 directory.
Let's check the documentation structure:
🧰 Tools
🪛 LanguageTool
[uncategorized] ~8-~8: Possible missing comma found.
Context: ...!** Before you start working on a code contribution make sure it will be accepted. If your ...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~37-~37: This phrase is redundant. Consider writing “moment” or “time”.
Context: ...f the code inmasterat that specific moment in time. Anyway, we'll tell you in PR comments ...(MOMENT_IN_TIME)
website/v2/guide/patterns/shared-configuration.md (2)
1-8: LGTM! Clear and concise introduction.The front matter and introduction effectively set up the purpose of the document.
105-105: LGTM! Well-organized reference link.The link reference is properly formatted and placed appropriately at the end of the document.
website/v2/guide/patterns/conditional-building.md (3)
13-41: LGTM! Well-structured example demonstrating the pattern.The code example effectively shows how to:
- Share common builder code
- Handle conditional branches
- Maintain type consistency with
.build()
63-103: LGTM! Clear demonstration of optional member handling.The example effectively demonstrates:
- Proper usage of
maybe_setters- Handling of
Option<T>values- Clear distinction between optional and required fields
142-144: LGTM! Clear and consistent terminology definitions.The glossary effectively defines the term "Member" and its variations, helping maintain consistent terminology throughout the documentation.
website/v2/guide/limitations.md (2)
29-70: Excellent explanation of lifetime parameter requirements!This section effectively explains the technical limitations of macros in Rust and provides both a solution and a helpful lint recommendation. The progression from problem to solution is clear and educational.
🧰 Tools
🪛 LanguageTool
[style] ~48-~48: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...er]` macro sees in the example above is just this: ```rust ignore fn example(value:...(REP_BE_JUST)
145-149: Well-organized references and glossary!The references and glossary terms are clear and helpful for understanding the documentation.
website/v2/config.mts (4)
1-2: LGTM!The import is clean and appropriate for the configuration file.
162-162: LGTM!The type validation using
satisfiesoperator ensures type safety of the sidebar configuration.
81-161:⚠️ Potential issueFix inconsistent URL paths in the reference section.
Similar to the guide section, the reference links need to be updated to match the
/v2/reference/base path.Update the URLs to match the base path. Example fix:
- link: "/reference/builder", + link: "/v2/reference/builder",This correction should be applied to all internal URLs in the reference section (excluding the docs.rs link).
#!/bin/bash # Verify if there are any docs at /reference/ path that should be under /v2/reference/ fd --type f "builder.md|bon.md" website/reference/
4-80:⚠️ Potential issueFix inconsistent URL paths in the guide section.
The sidebar is mounted at
/v2/guide/, but the links are using/guide/. This mismatch could lead to 404 errors.Update the URLs to match the base path. Example fix for the first item:
- link: "/guide/overview", + link: "/v2/guide/overview",This correction should be applied to all URLs in the guide section.
website/v2/guide/compatibility.md (4)
1-2: Well-structured documentation with clear sections!The document is organized logically with consistent sections, each containing an introduction, explanation, and practical examples. This structure effectively guides readers through different compatibility scenarios.
Also applies to: 3-4, 51-52, 81-82, 133-134, 178-179
205-207: Excellent inclusion of a glossary!The glossary effectively defines technical terms in multiple forms (Member/member/members), which helps maintain consistency throughout the documentation.
87-131: Excellent use of VitePress code groups!The code examples are well-formatted using VitePress's code-group feature, making it easy to switch between different implementation approaches.
1-207: Verify content migration strategy for v3.Since this PR is preparing for a docs split for v3, please confirm if this compatibility guide:
- Should be migrated to v3 as-is
- Needs updates for v3-specific compatibility concerns
- Should remain in v2 only
✅ Verification successful
Keep compatibility guide in v2 documentation
The compatibility guide should remain in the v2 documentation because:
- There's no v3 directory structure yet in the repository
- The content specifically documents v2.x compatibility patterns
- Blog posts indicate v3 is not yet planned ("If we ever make a
bon 3.0(which we have no reason to yet)")When v3 development begins, a new compatibility guide can be created specifically for v3-related changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if similar content exists in v3 docs fd -t f -e md compatibility website/v3Length of output: 138
Script:
#!/bin/bash # Check if v3 directory exists and its structure fd -t d v3 # Check current directory structure under website fd -t d . website # Look for any migration-related tasks or plans in documentation rg -i "migration|v3" websiteLength of output: 4534
🧰 Tools
🪛 LanguageTool
[style] ~83-~83: This phrasing can be wordy. For improved clarity, try opting for something more concise.
Context: ...to the member name to mark it as unused for the time being. The builder API won't change if you do...(FOR_THE_TIME_BEING)
website/v2/guide/alternatives.md (2)
29-34: LGTM!The explanation of the function builder fallback paradigm is clear and well-reasoned.
93-105: LGTM!All references are properly organized and correctly linked throughout the document.
website/.vitepress/config.mts (4)
4-4: LGTM: Import addition aligns with documentation versioning.The addition of v2 config import follows the existing pattern and supports the documentation split strategy.
27-27: Verify no critical documentation is excluded.The exclusion patterns look reasonable, but let's verify we're not accidentally excluding any important documentation files.
#!/bin/bash # Description: Check for potential documentation files in excluded paths # Expected: No critical documentation files should be found echo "Files in infra/ that might contain documentation:" fd -e md -e mdx . infra/ echo "Checking if README.md contains unique documentation not present elsewhere:" rg -l "^#\s+" README.md
78-78: Consider v3 documentation preparation.While the addition of v2 sidebars is correct, since this PR is preparing for v3, consider:
- Whether v3 sidebar configuration should be included now
- If version switching UI needs updates
#!/bin/bash # Description: Check version-related configurations # Expected: Consistent version references across config files echo "Checking version references in config files:" rg -l "v3|version" website/.vitepress/ echo "Checking for v3 documentation files:" fd -e md -e mdx . website/v3/Consider creating a placeholder for v3 sidebar configuration now to maintain a clear upgrade path. This could help prevent potential merge conflicts in future PRs.
9-10: Verify description consistency across documentation.The updated description is more comprehensive and better reflects the project's capabilities. Let's ensure this description is consistent with other key documentation files.
✅ Verification successful
Description is consistent across documentation
The description in the VitePress config matches the crate's description in
Cargo.tomlexactly:
"Next-gen compile-time-checked builder generator, named function's arguments, and more!"This description is also well-aligned with the more detailed explanation in the README.md, which describes
bonas "a Rust crate for generating compile-time-checked builders for functions and structs" and mentions the named parameters functionality. The consistency across these key documentation files indicates that the description accurately represents the project's capabilities.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for description consistency across key documentation files # Expected: Similar or matching descriptions in these files # Check README and package metadata files echo "Checking description consistency in key files:" rg -i "description|tagline" README.md Cargo.toml package.jsonLength of output: 630
Script:
#!/bin/bash # Let's try a different approach to find description-related content # First, let's check the root README echo "=== README.md content ===" cat README.md echo -e "\n=== Searching for description in markdown files ===" fd -e md -e mdx . website/ -x rg -i "description.*compile-time|builder generator" echo -e "\n=== Checking package metadata ===" # Try both root and website directory for package files fd "package.json|Cargo.toml" . -x cat {}Length of output: 22148
website/v2/guide/overview.md (1)
31-251: Well-structured and comprehensive code examples.The code examples effectively demonstrate the key features of the
boncrate:
- Clear progression from basic to advanced usage
- Good use of focus annotations to highlight important parts
- Comprehensive coverage of features
🧰 Tools
🪛 LanguageTool
[uncategorized] ~57-~57: Possible missing comma found.
Context: ...der for associated methods. For this to work you need to add a#[bon]macro on top...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~99-~99: This phrase is redundant. Consider using “inside”.
Context: ...of. For example, the#[builder]macro inside of theimplblock can't see the `impl Co...(OUTSIDE_OF)
[style] ~101-~101: This phrase is redundant. Consider using “inside”.
Context: ...evel of nesting. The#[builder]macro inside of theimplblock can't just break out o...(OUTSIDE_OF)
[uncategorized] ~114-~114: Possible missing comma found.
Context: ...To follow the usual Rust builder naming conventionsbontreats the method namednewins...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~114-~114: This phrase is redundant. Consider using “inside”.
Context: ...onsbontreats the method namednewinside of the impl block specially. It generates ...(OUTSIDE_OF)
[uncategorized] ~122-~122: Possible missing comma found.
Context: ...thods not callednewand for any free function the naming is a bit different: | Start...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~154-~154: Possible missing comma found.
Context: ...``` ::: tip#[derive(Builder)]on a struct generates builder API that is fully com...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~163-~163: This phrase is redundant. Consider using “inside”.
Context: ...o potential panics andunwrap()calls inside of the builder. ##Option<T>values are...(OUTSIDE_OF)
website/v2/guide/patterns/into-conversions-in-depth.md (1)
1-379: LGTM! Comprehensive and well-structured guide.The document provides an excellent in-depth exploration of
Intoconversions, with clear examples and practical advice. The structure effectively guides readers through the decision-making process of when to use and avoidIntoconversions.🧰 Tools
🪛 LanguageTool
[style] ~12-~12: The phrase ‘pretty much’ can be informal. To strengthen your writing, consider removing it or replacing it with an adverb.
Context: ...fore you proceed. Reading their docs is pretty much enough. For example, you should know th...(PRETTY_MUCH)
[style] ~31-~31: Consider removing “of” to be more concise
Context: ...conversions usually make sense only if all of the following are true (AND): ::: tip The...(ALL_OF_THE)
[style] ~36-~36: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...t performance-sensitive. 2. The builder is going to be used with literal values a lot or re...(GOING_TO_WILL)
[uncategorized] ~36-~36: Possible missing comma found.
Context: ... going to be used with literal values a lot or require wrapping the values. ::: ...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~183-~183: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...n pose a bottleneck for your application and you need to see every place in code whe...(COMMA_COMPOUND_SENTENCE)
[grammar] ~229-~229: If ‘type’ is a classification term, ‘a’ is not necessary. Use “type of”. (The phrases ‘kind of’ and ‘sort of’ are informal if they mean ‘to some extent’.)
Context: ...10. When the compiler can't infer the type of a numeric literal it falls back to assign...(KIND_OF_A)
[uncategorized] ~229-~229: Possible missing comma found.
Context: ...piler can't infer the type of a numeric literal it falls back to assigning the type `i3...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~229-~229: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... for an integer literal andf64for a floating point literal. In this casei32is inferred...(EN_COMPOUND_ADJECTIVE_INTERNAL)
[formatting] ~229-~229: Consider inserting a comma after an introductory phrase for better readability.
Context: ...andf64for a floating point literal. In this casei32is inferred, which isn't converti...(IN_THAT_CASE_COMMA)
[uncategorized] ~235-~235: Possible missing comma found.
Context: ...r needs to infer that generic type from usage unless it's specified explicitly. A cla...(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~252-~252: As an alternative to the over-used intensifier ‘really’, consider replacing this phrase.
Context: ...ects a parameter of typeIpAddr. It's a really simple exercise for the compiler in this case ...(EN_WEAK_ADJECTIVE)
[uncategorized] ~294-~294: A comma may be missing after the conjunctive/linking adverb ‘Thus’.
Context: ...compiler a single type that it accepts. Thus the compiler can't decide which type to...(SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA)
[formatting] ~294-~294: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ip_addrvariable in the original code, because there can be many that make sense. I....(COMMA_BEFORE_BECAUSE)
[grammar] ~334-~334: The verb form ‘code’ does not seem to be suitable in this context.
Context: ... .build();When we compile this code we get the following error:log .ma...(THIS_VBP_DT)
[typographical] ~334-~334: Consider inserting a comma for improved readability.
Context: ....build();When we compile this code we get the following error:log .maybe...(INITIAL_ADVP_COMMA)
[style] ~342-~342: This phrase is redundant. Consider using “inside”.
Context: ...e many potential candidates for the_inside of theOption<_>. This is because the si...(OUTSIDE_OF)
[uncategorized] ~349-~349: Possible missing comma found.
Context: ...!code ++] ``` Before we enabledIntoconversions the signature provided a hint for the c...(AI_HYDRA_LEO_MISSING_COMMA)
[formatting] ~353-~353: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...de which one you meant. And this matters, becauseOption<&str>andOption<String>are...(COMMA_BEFORE_BECAUSE)
[uncategorized] ~355-~355: Possible missing comma found.
Context: ...n they areNone. To work around this problem the caller would need to explicitly spe...(AI_HYDRA_LEO_MISSING_COMMA)
| <table> | ||
| <tbody> | ||
| <tr> | ||
| <td> | ||
| <div style="display: flex; align-items: center"> | ||
| <VPSocialLink | ||
| icon="discord" | ||
| link="https://discord.gg/QcBYSamw4c" | ||
| /> | ||
| <a href="https://discord.gg/QcBYSamw4c">Discord</a> | ||
| </div> | ||
| </td> | ||
| <td>Here you can leave feedback, ask questions, report bugs, or just write "thank you".</td> | ||
| </tr> | ||
| <tr> | ||
| <td> | ||
| <div style="display: flex; align-items: center"> | ||
| <VPSocialLink | ||
| icon="x" | ||
| link="https://x.com/veetaha" | ||
| /> | ||
| <a href="https://x.com/veetaha" class="nobr">X (Twitter)</a> | ||
| </div> | ||
| </td> | ||
| <td>Profile of the maintainer. There are only posts about <code>bon</code> and Rust in general here.</td> | ||
| </tr> | ||
| </tbody> | ||
| </table> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using VitePress built-in components for social links.
The current table structure could be simplified using VitePress's built-in components for a more consistent look and feel with the rest of the documentation.
Consider using VPTeamMembers or a custom container with VPSocialLink:
::: info Social Links
<div class="social-links">
<div class="social-link">
<VPSocialLink icon="discord" link="https://discord.gg/QcBYSamw4c" />
<span>Discord - Here you can leave feedback, ask questions, report bugs, or just write "thank you".</span>
</div>
<div class="social-link">
<VPSocialLink icon="x" link="https://x.com/veetaha" />
<span>X (Twitter) - Profile of the maintainer. There are only posts about <code>bon</code> and Rust in general here.</span>
</div>
</div>
:::
<style>
.social-links {
display: flex;
flex-direction: column;
gap: 1rem;
}
.social-link {
display: flex;
align-items: center;
gap: 0.5rem;
}
</style>| <script setup> | ||
| import { data as version } from '/data/version.data' | ||
| import VPSocialLink from "vitepress/dist/client/theme-default/components/VPSocialLink.vue"; | ||
| const [_, versionWildcard] = version.match(/(\d+.\d+).\d+/); | ||
| </script> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider making version extraction more robust.
The current regex pattern assumes a strict semantic versioning format. Consider:
- Using a more robust pattern that handles pre-release versions (e.g.,
1.0.0-alpha.1). - Using named capture groups for clarity.
-const [_, versionWildcard] = version.match(/(\d+.\d+).\d+/);
+const { groups: { majorMinor } } = version.match(/^(?<majorMinor>\d+\.\d+)(?:\.\d+|[-+].+)?$/);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <script setup> | |
| import { data as version } from '/data/version.data' | |
| import VPSocialLink from "vitepress/dist/client/theme-default/components/VPSocialLink.vue"; | |
| const [_, versionWildcard] = version.match(/(\d+.\d+).\d+/); | |
| </script> | |
| <script setup> | |
| import { data as version } from '/data/version.data' | |
| import VPSocialLink from "vitepress/dist/client/theme-default/components/VPSocialLink.vue"; | |
| const { groups: { majorMinor } } = version.match(/^(?<majorMinor>\d+\.\d+)(?:\.\d+|[-+].+)?$/); | |
| </script> |
|
|
||
| ::: | ||
|
|
||
| The default value will be lazily computed inside of the [finishing function](#finish-fn) (i.e. `build()` or `call()`). It is computed only if the setter for the member wasn't called or `None` was passed to the `maybe_{member}()` setter. |
There was a problem hiding this comment.
Fix invalid link fragments in the documentation.
The following link fragments appear to be invalid:
- Line 663: Link to finishing function
- Line 868: Link to start function
- Line 874: Link to finish function
- Line 1216: Link to start function
Please verify and update these links to point to the correct sections.
Also applies to: 868-868, 874-874, 1216-1216
🧰 Tools
🪛 LanguageTool
[style] ~663-~663: This phrase is redundant. Consider using “inside”.
Context: ...e default value will be lazily computed inside of the finishing function (i...(OUTSIDE_OF)
🪛 Markdownlint
663-663: null
Link fragments should be valid(MD051, link-fragments)
Part of #156
Summary by CodeRabbit
Release Notes
New Features
bonRust crate, including sections on optional members, fallible builders, and shared configurations.Bug Fixes
Documentation
#[builder]and#[bon]macros.Chores