-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PrintMembers method in record is unused #52421
Comments
Agree that we should not be emitting the suggestion / diagnostic around an unused member here as the member is used in |
The diagnostic is IDE0051. Moved to Area-IDE |
This is a little challenging as we have no way to get insight for the compiler generated methods (Afaict). Is tehre way, for example, to get the IOp tree for tehse synthesized methods? |
Agree. Not sure how the IDE can do it as currently spec'd out unless we expose this info via the API somehow. That could be done but I'm a bit hesistant. Not strong hesistant but thoughtful hesistant. Makes me wonder though. Is there a strong reason we required these to be |
One thing that would be helpful (and i think has come up a few times in the past) would be a way to say: given this ISymbol, provide the IOp trees for it. We could then walk the implicit, but eixsting, methods in the type to see what htey actually used. -- Or, we go whole hog and this analysis moves entirely to compiler, as compiler has the entire insight of what is or isn't used :) |
Woah woah now ... let's not get crazy here ;)
Any place I can read up on that discussion? |
I'll see if i can find. But it may have already been solved in one case. I think this was in teh context of analyzers and we added RegisterOperationBlockAction for this purpose. So in this case, it's likely a question of if these synthesized symbols show up in those callbacks. If so, IDE could likely make this work based on that. |
The analyzer registers a callback for generated code. The IOperation tree is expected to contain an accurate representation of the contents of the |
One thing that might be necessary woudl be a way for an analyzer to opt into hearing about iops for synthesized (or IsImplicit) members. Taht, or we could treat this just as a straight up bug that these members are not included in iop. I'm curious what @mavasani thinks. |
@CyrusNajmabadi That already exists - the analyzer can invoke Line 45 in dc24c3d
|
Do we know at what state of the compilation pipeline do we add this synthesized |
Ah, so I did a little more digging and figured there are 2 separate concepts for generated code:
I believe it was a design decision made in very early stages of analyzer design that compiler synthesized code is likely never useful for analyzer authors as (a) it would never have syntax or place to report diagnostics and (b) would be pretty much self contained. This no longer seems to be the case for records as synthesized |
Records really do blur the lines here. Those members are really a public part of the type, with relevant code in it. It's just as if they were generated into a different partial part. That really separates them out from things that are mere implemetnation details and whose semantics on their own really don't affect surround code. I don't have a good answer here, but i think we should pull in the right set of people to discuss this. |
Presumably we know if PrintMembers is Synthesized or not? Given that, could we say that ToString() is no longer considered synthesized when PrintMembers isn't? Effectively, non-synthesized is viral: if synthesized code calls into something non-synthesized then it also becomes non synthesized. We could still mark it with the generated attribute so most analyzers would ignore it, but ones that are equipped to handle it would then see it in that case, or ignore it still when everything is synthesized? |
Agree with your suggestion @chsienki. |
@mavasani Implicit symbols are skipped from symbol and declaration callbacks, but we should still be getting operation callbacks for executable code contained in them. |
This is why the containing type and method for top-level statements is considered non-synthesized. |
No, we skip them completely - there are no callbacks whatsoever for implicit symbols and nodes/operations within it. That has been the design since v1 of the analyzer driver. |
That makes sense for cases where two representations for the same code exist (e.g. |
@mavasani fwiw, I don't think this is accurate. |
This was done specifically to enable analyzer callbacks in top-level statements. The change was made under the definition that |
This seems to have gotten a bit stale. Should we maybe schedule 15 minutes to chat about this to see how we want to proceed here? |
@sharwell Wouldn't this still be problematic for: public sealed record R
{
public override string ToString() => string.Empty;
} Here, |
Version Used:
VS 16.9
🔗 Also filed as AB#1305928
Steps to Reproduce:
https://sharplab.io/#v2:EYLgtghgzgLgpgJwD4AEBMBGAsAKBQBgAIUMA6AFTgA8YBuXXKOCAGzgBNCE4BjAewScAwoQDeuQpJQBmYhiIR6OSYQAOCAJYA3CPELA+fFoQAKmgHYwAsnDDBEUABQBlGBYDmAIQCuGlu0R9X39EAEoJSXFlFRVgYICEUgBBVVU4c3ZHACIIQgBeQizCAGpCCFClGJUUAHZCN284SskAX1w2nAjJXHRCAEUxLrkANmIAFkIrCA1zR3DoyKGqkR58wnM4AHdCITnmqp2+cygjOFIAdU14Rx4KPlcPOYqhjpagA==
Expected Behavior:
No warning about unused PrintMembers since it is used implicitly by record ToString.
Actual Behavior:
Unused method PrintMembers .
The text was updated successfully, but these errors were encountered: