Block calls to scope functions in .biecpparam files

[jeskew]

Resolves #11902

The error message currently shown when a scope function is used in a .bicepparam file is unhelpful. These functions should only be defined in .bicep files so that template authors get actionable error messages if they try to use one.

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Test this change out locally with the following install scripts (Action run 6264671957)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 6264671957

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 6264671957"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 6264671957

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 6264671957"

[github-actions]

Test Results

     132 files  ±0       132 suites  ±0   3h 27m 50s ⏱️ +44s
10 552 tests +2  10 552 ✔️ +2  0 💤 ±0  0 ❌ ±0 
50 759 runs  +8  50 759 ✔️ +8  0 💤 ±0  0 ❌ ±0 

Results for commit 198ac50. ± Comparison against base commit f3276e7.

♻️ This comment has been updated with latest results.

[anthony-c-martin]

I'm not suggesting you make this change now (more interested in just getting your thoughts on it), but in the long run, I've been wondering if it would be less error-prone (and possibly better user experience) to have a "usage" property on the function overload - e.g.:

new FunctionOverloadBuilder("resourceGroup")
    .WithReturnResultBuilder(GetResourceGroupReturnResult, new ResourceGroupScopeType(Enumerable.Empty<FunctionArgumentSyntax>(), Enumerable.Empty<TypeProperty>()))
    .WithGenericDescription(resourceGroupGenericDescription)
    .WithDescription("Returns the current resource group scope.")
    .WithPermittedUsage(FunctionUsage.BicepFileOnly)
// or     .WithPermittedUsage(Usage.BicepParamsFileOnly)
    .Build(),

AFAIK we already have a similar capability to restrict the usage of getSecret() which we might be able to generalize more.

It also feels like it would generally be useful to shift in the direction of separating out "static" namespace functionality, rather than throwing away and rebuilding the namespace on every keypress (when profiling the LS, I this appeared to be one of the most expensive operations we do). Conceptually it's a bit weird that there are multiple different definitions of the namespace, depending on the Bicep file or e.g. targetScope declarations.

[jeskew]

That approach makes sense to me, but we should be able to hold on to copies of static namespace types across compilations even with the current approach. Feature-flagged and file format-specific functionality will vary by path, but we would only need to rebuild namespace types in the LS if a bicepconfig.json file were added or modified.

If we wanted to just hold onto a singleton, I think we would need to add a .WithRequiredFeatures(Func<IFeatureProvider, bool> predicate) method in addition to .WithPermittedUsage(FunctionUsage usage).

[anthony-c-martin]

Thanks for fixing this!