Skip to content
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

[API Compat] add rule to make sure that a member is not made more visible #23904

Closed
Tracked by #23910
safern opened this issue Feb 12, 2022 · 2 comments · Fixed by #27929
Closed
Tracked by #23910

[API Compat] add rule to make sure that a member is not made more visible #23904

safern opened this issue Feb 12, 2022 · 2 comments · Fixed by #27929
Assignees
Milestone

Comments

@safern
Copy link
Member

safern commented Feb 12, 2022

This rule should make sure that a member that is protected or protected internal in the implementation is the same in the contract and is not promoted to public.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Request triage from a team member label Feb 12, 2022
@safern safern added this to the 7.0.1xx milestone Feb 12, 2022
@safern safern removed the untriaged Request triage from a team member label Feb 12, 2022
@smasher164
Copy link
Member

https://docs.microsoft.com/en-us/dotnet/core/compatibility/ mentions that
✔️ ALLOWED: Expanding the visibility of a type
✔️ ALLOWED: Restricting the visibility of a protected member when the type has no accessible (public or protected) constructors, or the type is sealed.
❌ DISALLOWED: Reducing the visibility of a type

so I think the rule should be mostly checking for the opposite of what is in the first comment.

@KalleOlaviNiemitalo
Copy link
Contributor

Those compatibility rules are for "Modifications to the public contract", but the description of this issue is in terms of "contract" vs. "implementation". If the contract assembly defines a member as public but the implementation assembly defines it as protected, then a non-derived class in a project that references the contract can access the member at compile time, but the access will fail at run time when the implementation is used. So the description is correct although written as if the implementation comes before the contract.

@ViktorHofer ViktorHofer modified the milestones: 7.0.1xx, Backlog Aug 18, 2022
@smasher164 smasher164 self-assigned this Sep 14, 2022
smasher164 added a commit that referenced this issue Sep 16, 2022
This change adds a rule to check that the visibility of a symbol does not change.

- By default, when not run in strict mode, it checks that the visibility of the symbol is not reduced.
- However, in strict mode, it also checks that the visibility is not expanded.

Fixes #23904
smasher164 added a commit to smasher164/sdk that referenced this issue Oct 7, 2022
This change adds a rule to check that the visibility of a symbol does not change.

- By default, when not run in strict mode, it checks that the visibility of the symbol is not reduced.
- However, in strict mode, it also checks that the visibility is not expanded.

Fixes dotnet#23904
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants