Add ConstantExpectedAttribute

[wzchua]

Contributes to #33771

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[GrabYourPitchforks]

Thanks for the tests as well!

@stephentoub - What do you make of the idea of adding unit tests like the below?

var attr = new ConstantExpectedAttribute { Min = 10, Max = 0 };
// assert blah blah

It's clearly incorrect to write that, but it's nonsense that should be caught at design time and not as part of the attribute's own logic. Would it ever make sense to include this as an "it's nonsense but the attribute setters shouldn't block this" check?

[stephentoub]

What do you make of the idea of adding unit tests like the below?

Seems reasonable.

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Contributes to #33771

Author:	wzchua
Assignees:	-
Labels:	area-System.Diagnostics, new-api-needs-documentation, community-contribution
Milestone:	-

[buyaa-n]

Thanks @wzchua, LGTM

[stephentoub]

I assume there are existing APIs, in particular in intrinsics, where this should be used? #30740 (comment) calls out some. Is there any issue tracking attributing those parameters? In general my preference is to use new APIs in the same PRs that add those APIs, in order to help validate them. As this has already been merged, it could be done in a follow-up.
cc: @GrabYourPitchforks

[buyaa-n]

Is there any issue tracking attributing those parameters?

Sure I was planning to create an issue for tracking the APIs needs this, created #63426

In general my preference is to use new APIs in the same PRs that add those APIs, in order to help validate them. As this has already been merged, it could be done in a follow-up.

Understand, for this one it was not clear what parameters of what API's needs this except the one you mentioned, hope @tannergooding would add the APIs to the new issue. Merged the PR so that it could be able to be used for the analyzer as soon as getting available for roslyn-analyzers repo.