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.

Sign up for GitHub

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

Jump to bottom

Provide a compiler level API to list used (or the opposite unused) references per compilation #37768

Closed
ivanbasov opened this issue Aug 6, 2019 · 5 comments
Closed

Provide a compiler level API to list used (or the opposite unused) references per compilation #37768

ivanbasov opened this issue Aug 6, 2019 · 5 comments
Assignees
@AlekseyTs
Labels
Area-Compilers Feature Request
Milestone
Compiler.Next

Comments

@ivanbasov
Copy link
Contributor

ivanbasov commented Aug 6, 2019 •
edited by jinujoseph
Loading

Required for #6763
@ivanbasov
Copy link
Contributor Author

Tagging @gafter and @jaredpar

@mikadumont mikadumont mentioned this issue Aug 6, 2019
Closed
5 tasks
@ivanbasov ivanbasov mentioned this issue Aug 6, 2019
Closed
@gafter
Copy link
Member

gafter commented Aug 7, 2019

This is not possible (too complex for the bar) in 16.3.

@gafter gafter modified the milestones: 16.4, Compiler.Next Aug 7, 2019
@jaredpar
Copy link
Member

jaredpar commented Aug 7, 2019

This is a significant work item for the compiler team: both in design and implementation. It's not going to meet our bar for 16.3 and almost certainly won't meet the bar for 16.4 either.

@Pilchie Pilchie mentioned this issue Aug 9, 2019
Closed
@AlekseyTs AlekseyTs self-assigned this Aug 21, 2019
@AlekseyTs
Copy link
Contributor

AlekseyTs commented Aug 21, 2019 •
edited
Loading

The following aspects should be taken into consideration:

  • If an assembly reference is removed, it might still be possible to compile successfully, but with different result (a different extension method is used, etc.).
  • Speculative binding triggered by SemanticModel should have no effect, shouldn't "pollute" the result.
  • A linked (NoPia) assembly is never added to the AssemblyRefs in the resulting assembly, however it should be referenced by the compilation if any types are used.
  • A references to a constant (constant fields/enum member) in source is replaced with underlying constant value in the resulting assembly and, by itself, doesn't add defining assembly to the set of AssemblyRefs. However, the build is going to fail if the defining assembly is not referenced by the compilation.
  • Similar to constants, compiler might optimize out usage of a type "used" in source (for example, an instance of a tuple is not actually created, etc.), but the type might still be required for a successful build.
  • Intermediate assemblies in the type forwarding chain are not added to the set of AssemblyRefs, but they should be among compilation references in order to compile successfully when the forwarding chain is used.
  • Some types are used by compiler implicitly without an explicit reference in source (runtime helpers, attributes, etc.). It is quite possible that compiler can silently change output when a certain API becomes available (no longer ambiguous if reference is removed) or becomes unavailable.
  • Compiler can embed or stop embedding some types (for example, attribute types for C# features) without resulting in a compilation error when the set of compilation references is changed.
  • Usage of a conditional API might not be reflected in AssemblyRefs, but the build is going to fail if the defining assembly is not referenced by the compilation.
  • A using/imports can refer to a declaration in an otherwise unused referenced assembly, resulting in an error if the reference is removed.
  • When a candidate for overload resolution becomes "bad" due to an assembly reference removal, that might cause an overload resolution failure even when the method is not the best candidate.

AlekseyTs added a commit to AlekseyTs/roslyn that referenced this issue Nov 13, 2019
@AlekseyTs
This is a beginning of work on dotnet#37768.
de4bee5 
Detect used assembly references from:
- explicit references to types in source;
- explicit references to namespaces in source;
- explicit references to fields in source;
- explicit method invocations in source;

Usings flagged by the compiler as unused shouldn’t contribute to the set of used references.
@AlekseyTs AlekseyTs mentioned this issue Nov 13, 2019
Merged
AlekseyTs added a commit that referenced this issue Nov 19, 2019
@AlekseyTs
Beginning of work on "Used Assembly References" feature. (#39807)
c5bc1e0 
This is a beginning of work on #37768.

Detect used assembly references from:
- explicit references to types in source;
- explicit references to namespaces in source;
- explicit references to fields in source;
- explicit method invocations in source;

Usings flagged by the compiler as unused shouldn’t contribute to the set of used references.
AlekseyTs added a commit to AlekseyTs/roslyn that referenced this issue Nov 25, 2019
@AlekseyTs
Track assemblies declaring well-known types used by a compilation.
297b0ba 
Related to dotnet#37768.
@AlekseyTs AlekseyTs mentioned this issue Nov 25, 2019
Merged
AlekseyTs added a commit that referenced this issue Nov 28, 2019
@AlekseyTs
Track assemblies declaring well-known types used by a compilation. (#…
6ef9ace 
…40010)

Related to #37768.
AlekseyTs added a commit to AlekseyTs/roslyn that referenced this issue Dec 4, 2019
@AlekseyTs
Record used assembly references for more scenarios.
bae7699 
- Merged extern aliases
- Embeddable attributes
- Usage of canonical definitions for NoPia embedded types
- nameof of a method
- Deconstruction
- Collection initializers

Related to dotnet#37768.
@AlekseyTs AlekseyTs mentioned this issue Dec 4, 2019
Closed
AlekseyTs added a commit to AlekseyTs/roslyn that referenced this issue Dec 20, 2019
@AlekseyTs
Record used assembly references for more scenarios.
f6ac474 
- Merged extern aliases
- Embeddable attributes
- Usage of canonical definitions for NoPia embedded types
- nameof of a method
- Deconstruction
- Collection initializers

Related to dotnet#37768.
AlekseyTs added a commit that referenced this issue Dec 31, 2019
@AlekseyTs
Move to the use site tracking for the purpose of recording used assem…
bb8f2df 
…blies (#40560)

The basic idea is that dependencies should be tracked along with use-site diagnostics and should be collected together with regular diagnostic messages and bubble up to the top. The final consumer of the combined diagnostics and dependencies is responsible for “registering” dependencies with the compilation or ignore them (due to the context, etc.). I believe this is a very robust approach and would require little maintenance going forward, because every time a symbol is used, a use-site diagnostics should be reported. We just need to keep doing that for every new feature and dependencies will be tracked automatically. Also, the code performing binding no longer needs to be context aware (should dependencies be tracked at this moment or not), they should always be tracked and collected along with the regular diagnostics and it is up to the consumer to decide what to do with them, if anything. For example, when SemanticModel performs binding, dependencies are not registered, etc.

Record used assembly references for more scenarios.

- Merged extern aliases
- Embeddable attributes
- Usage of canonical definitions for NoPia embedded types
- nameof of a method
- Deconstruction
- Collection initializers

Related to #37768.
@jcouv
Copy link
Member

jcouv commented Oct 4, 2021

@AlekseyTs Can we close this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AlekseyTs AlekseyTs

Labels
Area-Compilers Feature Request
Projects
None yet
Milestone
Compiler.Next
Development

No branches or pull requests
5 participants
@jaredpar @gafter @ivanbasov @AlekseyTs @jcouv