new lint: add call_missing_target_feature lint

[folkertdev]

changelog: [call_missing_target_feature]: was added

This PR adds a lint for missing target features.

Motivation

A function that requires a target feature (e.g. #[target_feature(enable = "avx2")] to indicate that avx2 instructions can be used) must be called from a context where these instructions are actually available. That check is part of the safety contract of the function. For correctness and performance, any function calling a function with a target feature must either

• also declare that target feature
• assert that the target feature is available (e.g. with the is_x86_feature_detected macro, or similar for the current target platform)

However, currently no warning is emitted when the user forgets to correctly annotate target features. My personal experience with zlib-rs is that it's just really easy to forget the annotation on some helper function, and to forget to check for target features in code review. Hence, this check.

Implementation

The implementation looks for function calls, then looks up if that function (the callee) has any target features, and if so, checks whether the caller also has these target features. Any missing target features are reported.

This lint is not always accurate, and I think should be off by default, but is very useful in e.g. simd-heavy codebases. Some #[cfg(allow(...)] are always required though in the function where the feature detection macro is called.

Questions

• The tests run into

  error: test got exit status: 1, but expected 0
   --> tests/ui/call_missing_target_feature.fixed:1:1
    |
  1 | #[target_feature(enable = "avx2")]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ after rustfix is applied, all errors should be gone, but weren't
  

  despite the suggestion being Applicability::MaybeIncorrect. I must be missing something here. The problem is that the function must also be marked as unsafe in this case. Still I think the suggestion is useful. Also inserting the unsafe seems complicated, but maybe that is possible?

cc @bjorn3 maybe you have phrasing suggestions?

[rustbot]

r? @dswij

rustbot has assigned @dswij.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[folkertdev]

probably rust-lang/rust#128852 is needed to fix the suggestion here and correctly insert the unsafe keyword

[Jarcho]

r? @Jarcho

I'll take a look at this within a couple of days.

[Jarcho]

Did an initial review. When ordering and performing checks try to make sure to optimize for the common case. For this it would be something like:

• Not a function call
• Called function has no target_features
• Not from an external macro (Not always true, but true for most crates)

[folkertdev]

Thanks for the review!

I've handled the comments and also rebased because some CI things had changed.