SAM/CFN json schema: handle of intrinsic functions

[jpinkney-aws]

Is your feature request related to a problem? Please describe.
Right now when we use intrinsic functions in YAML we often get error messages such as:
Incorrect type. Expected "string".

E.g.

AWSTemplateFormatVersion: 2010-09-09
Transform: AWS::Serverless-2016-10-31
Resources:
  sample:
    Type: AWS::Logs::MetricFilter
    Properties:
      LogGroupName: !Join [ ":", [ a, b, c ] ] <- Incorrect type. Expected "string"

from #1974 (comment).

This issue can also be seen a couple times in: #1978.

We should work on improving support for intrinsic functions (either in this extension or through VSCode-YAML) so that all YAML is successfully validated.

Describe the solution you'd like
There's a couple quick ideas that might help:

1. Work with VSCode-YAML to create an API to disable validation when it sees certain intrinsic types
2. Work with VSCode-YAML to create an API to allow us to provide custom validation on intrinsic values. This means we would be able to validate whether or not an intrinsic function is behaving correctly and provide feedback to YAML writers if there might be an error

Describe alternatives you've considered
See if we can somehow handle intrinsic functions better through this extension

Additional context
Intrinsic function reference: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html

[rlucredio]

Hello guys. Please, is there any workaround that can be done in the meantime?
My config:

• VSCode 1.71.2
• AWS Toolkit 1.50.0
  I'm not using goformation like sam.schema.json: invalid policy document #1974
  Thanks

[justinmk3]

Workarounds

Current known workarounds:

1. install the cfn-lint vscode extension: https://github.com/aws-cloudformation/cfn-lint-visual-studio-code
2. manually set the schema (per-file) as described in SAM json schema: cannot change schema in template.yaml file #3012 (comment)

[amandalishus]

I just installed the cfn-lint VSCode extension today, and I've tried a few different ways of updating my "yaml.customTags" setting, but I'm still seeing many problems with this. One easily reproducing option is to declare a parameter of type CommaSeparatedValues and then use Fn::Select (or !Select) on it. However, it also seems that any time I use a function within a function (i.e. !ImportValue !Sub "${Environment}-value") it finds some way to make it annoying if not impossible. I know there are a lot of different combinations when it comes to using two functions, but it seems like a lot of these problems would be helped if we could declare a return type for functions when they're defined in "yaml.customTags". Just a thought... you're the pros :)