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

Kill DeclarationType.ModuleOption #2861

Closed
retailcoder opened this issue Mar 14, 2017 · 0 comments
Closed

Kill DeclarationType.ModuleOption #2861

retailcoder opened this issue Mar 14, 2017 · 0 comments
Assignees
@Vogel612
Labels
difficulty-01-duckling Issue where no particularly involved knowledge of the internal API is needed. enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. technical-debt This makes development harder or is leftover from a PullRequest. Needs to be adressed at some point. up-for-grabs Use this label in conjunction with a difficulty level label, e.g. difficulty-02-ducky
Projects
CodeName: Cucumber

Comments

@retailcoder
Copy link
Member

That one predates version 1.0 I think. Module options aren't declarations, and DeclarationType.ModuleOption is used in 12 places in the solution:

  • In API.Declaration - it should die here too
  • In Symbols.Declaration - it's part of the declaration types we exclude as "never array" (duh!)
  • In Symbols.DeclarationFinder - where it's special-cased so as to return the parent module when it's selected.
  • In Symbols.DeclarationSymbolsListener - which creates the module option "declarations".
  • In FindSymbolViewModel - where it's also explicitly excluded from navigatable declarations.
  • In OptionBaseInspection - IMO the inspection itself should be removed.
  • In OptionExplicitInspection - we should be inspecting the parse tree instead.
  • In RenameModel.AcquireTarget - where it's also being excluded; you can't rename that declaration.
  • In UseMeaningfulNameInspection - where it's also being excluded, for the same reason as above.

So basically all usages beyond creating the declarations are for special-casing the declaration type.

Burn.
@retailcoder retailcoder added difficulty-01-duckling Issue where no particularly involved knowledge of the internal API is needed. enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. technical-debt This makes development harder or is leftover from a PullRequest. Needs to be adressed at some point. up-for-grabs Use this label in conjunction with a difficulty level label, e.g. difficulty-02-ducky labels Mar 14, 2017
BZngr added a commit to BZngr/Rubberduck that referenced this issue Mar 16, 2017
@BZngr
Removed Option Explicit module options from test cases to avoid false…
5360369 
… failures after rubberduck-vba#2861 is fixed
@Vogel612 Vogel612 added this to TODO in CodeName: Cucumber Jun 21, 2017
@Vogel612 Vogel612 self-assigned this Oct 4, 2017
@Vogel612 Vogel612 moved this from TODO to Done in CodeName: Cucumber Oct 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Vogel612 Vogel612

Labels
difficulty-01-duckling Issue where no particularly involved knowledge of the internal API is needed. enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. technical-debt This makes development harder or is leftover from a PullRequest. Needs to be adressed at some point. up-for-grabs Use this label in conjunction with a difficulty level label, e.g. difficulty-02-ducky
Projects
CodeName: Cucumber
  
Done
Milestone
No milestone
Development

No branches or pull requests
2 participants
@retailcoder @Vogel612