We should document actionable steps for some warning codes

There are some warning codes that explain to you why an issue happens, but then they leave you with no actionable item. Am I able to suppress it in a certain scenario? Is it always dangerous?
Maybe we should have documented certain common scenarios, if a warning gives false positives 50% of the time, how to recognize them and suppress them. For example, IL2060 sounds like a very dangerous pattern since it cannot be analyzed statically by the linker, but they are certain scenarios that make it trim safe without user action and can be suppressed. Is it something that we can document?
Another case is when we know a pattern will always be unsafe, we could link the warning to documentation on how to use descriptor files/dynamic dependency.
Is this something we can include in the error-codes.md?