Implemented modes in AsynchronousFunctionNames rule

[webwarrior-ws]

Mode OnlyPublicAPIsInLibraries only runs in projects that are likely library projects.
Mode AnyPublicAPIs flags all public APIs like before.
Mode AllAPIs also flags (give violations about) internal, private, and nested APIs.

Contributes to #517.

[knocte]

Missing change in docs.

[greptile-apps]

Greptile Overview

Confidence Score: 2/5

• Not safe to merge until config defaulting is fixed
• AsynchronousFunctionNames switched from EnabledConfig to RuleConfig<Config> but is still constructed via constructRuleWithConfig, which skips the rule entirely when config is omitted. The repository default fsharplint.json enables the rule without a config block, so the rule will be silently disabled by default after this change.
• src/FSharpLint.Core/Application/Configuration.fs, src/FSharpLint.Core/fsharplint.json

Important Files Changed

Filename	Overview
docs/content/how-tos/rules/FL0096.md	Docs updated to show new mode config for FL0096; example disables the rule but now includes config.mode.
src/FSharpLint.Core/Application/Configuration.fs	Changes AsynchronousFunctionNames config type to RuleConfig<...> and constructs it with constructRuleWithConfig, which currently skips the rule entirely when config is omitted (breaking { enabled: true } behavior and default config).
src/FSharpLint.Core/Rules/Conventions/Naming/AsynchronousFunctionNames.fs	Adds Config.Mode and new modes logic (library heuristic + access level + nested behavior). Main functional risk is config defaulting handled elsewhere, not in this file.
src/FSharpLint.Core/Rules/Conventions/Naming/SimpleAsyncComplementaryHelpers.fs	Moves AsynchronousFunctionsMode to shared helper and continues using Config.Mode; no functional logic changes in this PR diff.
src/FSharpLint.Core/Rules/NamingHelper.fs	Introduces shared AsynchronousFunctionsMode DU under Helper.Naming.Asynchronous for reuse by multiple rules.
tests/FSharpLint.Core.Tests/Rules/Conventions/Naming/AsynchronousFunctionNames.fs	Updates tests to pass config to rule and adds new fixtures covering AllAPIs (non-public + nested bindings).
tests/FSharpLint.Core.Tests/Rules/Conventions/Naming/SimpleAsyncComplementaryHelpers.fs	Updates tests to use shared AsynchronousFunctionsMode and to pass Mode = AnyPublicAPIs explicitly.

Sequence Diagram

sequenceDiagram
    participant UserCfg as fsharplint.json
    participant Config as Configuration.fs
    participant Ctor as constructRuleWithConfig
    participant AFN as AsynchronousFunctionNames.rule
    participant Runner as AsynchronousFunctionNames.runner
    participant Heur as LibraryHeuristics

    UserCfg->>Config: Deserialize RuleConfig<AsynchronousFunctionNames.Config>
    Config->>Ctor: constructRuleWithConfig AFN.rule (if enabled)
    alt config block present
        Ctor->>AFN: rule(config)
        AFN->>Runner: Runner = runner config
        Runner->>Heur: howLikelyProjectIsLibrary(projectFileName)
        Runner-->>Config: Suggestions emitted/empty
    else config omitted (Config=None)
        Ctor-->>Config: returns None (rule not constructed)
        Note over Config,Ctor: Enabled rule becomes effectively disabled
    end

Loading

[greptile-apps]

_{7 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (2)

src/FSharpLint.Core/Application/Configuration.fs
Rule silently disabled
constructRuleWithConfig only applies rule when ruleConfig.Config is Some, so enabling asynchronousFunctionNames without a config block results in the rule not being constructed at all (i.e., effectively disabled). This is a behavior change from the previous EnabledConfig version and currently affects the default fsharplint.json which has "asynchronousFunctionNames": { "enabled": true }.

This needs a default AsynchronousFunctionNames.Config (e.g. AnyPublicAPIs) similar to constructTypePrefixingRuleWithConfig so that { "enabled": true } still enables the rule.

---

src/FSharpLint.Core/fsharplint.json
Enabled rule missing config
asynchronousFunctionNames is enabled here but provides no config. With the updated config type (RuleConfig<AsynchronousFunctionNames.Config>), this will deserialize to Config = None and (via constructRuleWithConfig) the rule won’t be constructed at all.

Either add a default mode here or change rule construction to apply a default when config is omitted.

[webwarrior-ws]

Missing change in docs.

Added new setting description to docs.

[knocte]

Not safe to merge until config defaulting is fixed

Actually, instead of defaulting to a mode when not specifying the mode (like TypePrefixing rule does), I'd prefer if we throw an exception in this case because in this case the rule is new (in the case of TypePrefixing, the rule already existed when we added the mode).

[webwarrior-ws]

Not safe to merge until config defaulting is fixed

Actually, instead of defaulting to a mode when not specifying the mode (like TypePrefixing rule does), I'd prefer if we throw an exception in this case because in this case the rule is new (in the case of TypePrefixing, the rule already existed when we added the mode).

The rule is constructed using constructRuleWithConfig, like most of rules that have config, and not like TypePrefixing which uses its own function constructTypePrefixingRuleWithConfig.

[knocte]

Not safe to merge until config defaulting is fixed

Actually, instead of defaulting to a mode when not specifying the mode (like TypePrefixing rule does), I'd prefer if we throw an exception in this case because in this case the rule is new (in the case of TypePrefixing, the rule already existed when we added the mode).

The rule is constructed using constructRuleWithConfig, like most of rules that have config, and not like TypePrefixing which uses its own function constructTypePrefixingRuleWithConfig.

So?

[webwarrior-ws]

Not safe to merge until config defaulting is fixed

Actually, instead of defaulting to a mode when not specifying the mode (like TypePrefixing rule does), I'd prefer if we throw an exception in this case because in this case the rule is new (in the case of TypePrefixing, the rule already existed when we added the mode).

The rule is constructed using constructRuleWithConfig, like most of rules that have config, and not like TypePrefixing which uses its own function constructTypePrefixingRuleWithConfig.

So?

So it is already functioning as you described, no need to change anything.

[knocte]

Ok great.

[knocte]

So it is already functioning as you described, no need to change anything.

Both rules yeah?

[webwarrior-ws]

So it is already functioning as you described, no need to change anything.

Both rules yeah?

Yes.