In the deferred path for Kind::Command, the sub_augment code already contains initial_app_methods and final_from_attrs (see lines 311-340). These methods are being applied twice: once eagerly at lines 362-363, and once more inside the deferred closure at line 365. This differs from the non-deferred path (lines 374-375) which only applies them once. This could cause duplicate method calls or incorrect command configuration. The deferred path should match the non-deferred path's structure and only include #sub_augment inside the defer closure without applying the methods eagerly outside.

The new defer attribute functionality lacks test coverage. No tests were found in the derive test suite (tests/derive/) that verify the correct code generation for #[command(defer = true)] or #[command(defer = false)]. Tests should verify both the deferred and non-deferred code paths, including proper handling of metadata methods and correct closure generation.

If we make the defer conditioned on unstable-v5 we'll get basic test coverage through the CI job that runs make test-next.

We can possibly get away without explicit defer tests since it would ideally be short lived.

#4959 specifies that only .subcommands() and .args() should be deferred

This is a bit brittle duplicating this but it is also "short lived". Hmm, maybe not so short considering how long v4 has been out so far and what that might mean for v5.

Let's set this up so that item.defer controls whether we pass in a defer call or a regular call.

Let's set this up so that item.defer controls whether we pass in a defer call or a regular call.

@epage Sorry, I did not get it. Could you, please, elaborate it a bit more?

This duplicates the entire body for how to initialize a Command. Instead, I would recommend doing something like:

let deferrable if item.defer() {
} else {
};

// ...

let #subcommand_var = #deferrable;

As discussed at #6225 (comment), we don't do "value or implied" attributes only "value attributes" or "implied attributes".

We need a test case for

    #[derive(Parser, Debug, PartialEq)]
    #[command(defer = true)]
    enum Cmd {
        Sub {
            #[arg(long)]
            flag: bool,
        },
    }

Addressed it in the most recent commits

We aren't verifying that the args weren't deferred

Addressed it in the most recent commits

The comment and test name depend on cfg(feature = "unstable-v4"). Once we stabilize v5, these will be stale.

Addressed it in the most recent commits

So gen_augments calls these and we are also calling them if defer is true. Why is that?

@epage Otherwise the ".about()" and similar options won't get applied eagerly and as such the --help won't have subcommand descriptions.

But we are generating them twice? Seems like that should be re-evaluated so we only generate them once.

The methods are not compute heavy at all. My CLI has 330 deeply nested command structs/enums and I do not observe any performance difference between master vs this PR. This is totally unnecessary "optimization".

should_panics aren't great because we can only assert one thing and the assertion is disconnected from the actual code. Please update the asserts in the body to reflect the actual behavior at this point in time.

Man, this is so pointless

You literally do it yourself: a0187c6. Why do you give me this pointless exercises?

An important role for PRs is to communicate which these are about.

Yes, should_panic is used in the tests today but not for observing one assert in a very long test, missing the others, but to check for specific debug asserts that exist in the build() call within the API.

The tests pass at the end of the day and this improves my CLI start up time from 6 seconds to 10 milliseconds. I will leave this PR at this state and won't continue addressing totally irrelevant review comments, I am done here.