Don't leak help_heading when flattening

[epage]

Please complete the following tasks

• I have searched the discussions
• I have searched the existing issues

Rust Version

rustc 1.55.0 (c8dfcfe04 2021-09-06)

Clap Version

v3.0.0-beta.4

Minimal reproducible code

use clap::Clap;

#[derive(Debug, Clone, Clap)]
#[clap(help_heading = "General")]
struct CliOptions {
    #[clap(flatten)]
    options_a: OptionsA,

    #[clap(flatten)]
    options_b: OptionsB,
}

#[derive(Debug, Clone, Clap)]
#[clap(help_heading = "HEADING A")]
struct OptionsA {
    #[clap(long)]
    should_be_in_section_a: Option<u32>,
}

#[derive(Debug, Clone, Clap)]
struct OptionsB {
    #[clap(long)]
    option_b: Option<u32>,
}

fn main() {
    CliOptions::parse();
}

Steps to reproduce the bug with the above code

cargo run -- --help

Actual Behaviour

option_b is in "HEADING A"

Expected Behaviour

option_b should be in `General

Additional Context

This is split out of #2785.

Similarly, we should also support setting help_heading when specifying flatten and it should push and pop the heading.

Debug Output

No response

[epage]

I'm assuming we'd need to add a get_heading_help and have the derive get it and then restore it afterwards.

[kbknapp]

Oddly enough I ran into exactly this at work the other day.

I'm assuming we'd need to add a get_heading_help and have the derive get it and then restore it afterwards.

Yeah that's the best way I can think of to do this in the least obtrusive manner. An alternative would be to have #[clap(help_heading = "Foo"] struct Foo; use Arg::help_heading individually on each field when creating the Arg struct instead of setting the "global" App help heading which sets the current heading for all future args added to the App until it's changed or reset.

[epage]

An alternative would be to have #[clap(help_heading = "Foo"] struct Foo; use Arg::help_heading individually on each field when creating the Arg struct instead of setting the "global" App help heading which sets the current heading for all future args added to the App until it's changed or reset.

Forgot to mention that I had considered this. I assumed people would want the setting to be inherited which this wouldn't allow. For example, clap-verbosity-flag probably wouldn't be so prescriptive as setting its own help heading, relying on inheriting it. We could extend the trait to allow passing in a heading, but I worry about that being a slippery slope for what goes in the trait interface.

Granted, now that I say this, the converse to this also needs to be implemented If someone sets the heading on a flatten, that should apply as an App heading and be reset afterwards so someone can set the heading on the clap-verbosity flags.

[pksunkara]

Related to #2785