This fixes the compiler suggestions; see rust-lang/rust#94074.

Technically this is a breaking change - previously, because of the parentheses, you could actually pass a tuple as the default value without wrapping it in parentheses - e.g. #[default(1, 1)]. Now you need to do #[default((1, 1))]. However, I don't think someone relied on this, as it looks like the wrong behavior.

Fields with r# prefixed didn't work due to the capitalize function not handling the prefix. Eg:

#[derive(Buildable)]
struct Foo {
  r#type: String,
}

This PR fixes the issue by stripping the r# when capitalizing the ident.

I suggest merging this as a squashed merge combining the commits into one.

Given the following code:

#[derive(Builder)]
struct MyStruct {
    #[default(Foo(0)]
    one: Foo,
}

struct Foo(i32);

The code fails since Foo doesn't implement Default. But this should not be the case since I'm providing a default through the attribute, and adding the where Foo: Default is uncecessary at that point.

where
  Foo: Default

Should only be applied if #[default] is given without a value.

The first thing I tried to find was the error messages, ended up finding them in the tweet. Copied the image into the README and brought the disclaimer to the top so it doesn't get lost as the README gets longer

I'm using makeit heavily with props for a web framework, and currently when a prop is an Option<T>, you have to write <MyComponent prop={Some(val)} />, but it would be much more desireable in my case to do <MyComponent prop={val} />.

Could the set_ methods generated for fields of type Option<T> take T directly rather than the option itself?

If needed, another method set_none could be generated for options which would set it to None.

For example

pub unsafe fn ptr_0(&mut self) -> *mut String {
    let inner = self.inner.as_mut_ptr();
    &raw mut (*inner).a
}

A reference in Rust gurantees that the memory is initialized. You need to use addr_of_mut to correctly model this.

Somewhat unrleated but I thought I'd mention it.

let ptr =
    &self as *const OrangeBuilder<AUnset, FieldB> as
        *const OrangeBuilder<ASet, FieldB>;
::core::mem::forget(self);
unsafe { ptr.read() }

That looks a lot like transmute. Is there a specific reason not to use transmute here? Also this is UB too, the docs for mem::forget

Any resources the value manages, such as heap memory or a file handle, will linger forever in an unreachable state. However, it does not guarantee that pointers to this memory will remain valid.

#[derive(Builder, Debug)]
struct Orange {
    a: String,
    b: String,
}
 
fn main() {
    let orange = Orange::builder()
        .set_a("xxx".into())
        .set_b(panic!())
        .build();
 
    dbg!(orange);
}

cargo +nightly miri run
 
The following memory was leaked: alloc1014 (Rust heap, size: 3, align: 1) {
    78 78 78                                        │ xxx
}

This can be addressed by using a scope guard.

It looks like the generated code puts everything into a private module named after the builder type. For example, looking at the sample code from the README:

use makeit::Builder;

#[derive(Builder)]
struct Foo<'a, T: std::fmt::Debug> {
    bar: &'a T,
    #[default(42)]
    baz: i32,
}

This produces an expansion like

mod FooBuilderFields {
    pub struct FooBuilder<…> { … }
    pub struct BarSet;
    pub struct BazSet;
    pub struct BarUnset;
    pub struct BazUnset;
    // impls …
}

And the generated documentation does not include the FooBuilder type:

If I know the module name I can write pub use FooBuilderFields::FooBuilder, but it feels like I shouldn't have to do that. The builder should just be available by default.

I can imagine a scenario in which someone might want to move the builder into a separate module, like pub mod builder { pub use super::FooBuilderFields::FooBuilder; } but that is a bit of an edge case and should require opt-in behavior.

Proposed behavior

The macro expansion should simply declare the FooBuilder type in the current module instead of inside the FooBuilderFields module, and it should mark it as pub if the decorated type itself is pub. Also see #7 in which I argue that the Buildable type should be removed and propose a #[builder(…)] attribute for renaming the builder() method and FooBuilder type as needed.

If I have an edge case where I want Foo to be public but I want the FooBuilder type to be moved into a different module, I can deal with that using existing visibility rules by writing something like:

mod foo {
    #[derive(makeit::Builder)]
    pub struct Foo<'a, T: std::fmt::Debug> {
        bar: &'a T,
        #[default(42)]
        baz: i32,
    }
}
pub use foo::Foo;
pub mod builder {
    pub use super::foo::FooBuilder;
}

I don't see any reason to make the BarSet/BarUnset/… types public by default so they can stay as they are.

I love the idea of this crate for writing builder patterns, but I want the use of this crate to be transparent to end-users. The comments on the Buildable trait say it exists to handle the edge case of the type already having a builder() method. I don't really understand why this is a problem; if the type already has one, why is it using makeit? Builder isn't something that can be applied to an existing type either, it's something used on a type as it's being defined. Instead I would simply prefer an optional #[builder(method = "builder")] attribute that lets me rename the builder method. This same attribute could also be used to rename the builder type (and wrapper module) as well.

I suppose today I can implement an inherent builder() method that invokes the trait method, but that's a bit awkward and shouldn't be necessary just to let clients of my type call its builder.