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

modify yardopts parsing to ignore hash and c-style comments #1070

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

eprothro
Copy link

@eprothro eprothro commented Feb 8, 2017

Description

Adds support for hash and c-style comments in .yardopts files.

We want this to be able to reduces developer confusion for those new to YARD. Devs can tend to see a .yardopts file, get confused, then just shrug and walk away.

Being able to comment the options can pull them in more easily, and allow for documenting options that may not be use currently but are of interest.

Example

# YARD options, see `yardoc -h`
# for valid options and descriptions

# parse inline documentation with
# rdoc markup formatting
--markup "rdoc"

# treat code mixed in via include
# and extend as first class citizens
# of the module without additional directives
--embed-mixins

# clear the yardoc database
# when requesting documentation
# --no-cache

# Additional files to add to documentation tree
-
CHANGELOG.md
CONTRIBUTING.md
LICENSE

Completed Tasks

  • [y] I have read the Contributing Guide.
  • [y] The pull request is complete (implemented / written).
  • [y] Git commits have been cleaned up (squash WIP / revert commits).
  • [y] I wrote tests and ran bundle exec rake locally (if code is attached to PR).

@coveralls
Copy link

coveralls commented Feb 8, 2017

Coverage Status

Coverage increased (+0.003%) to 93.442% when pulling 58f63f4 on eprothro:yardopts-comments into 89ea314 on lsegal:main.

Copy link
Owner

@lsegal lsegal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the behavior cannot be accepted as-is. Allowing comments in the middle of a line would create way too much parsing ambiguity. See the inline comments for examples of cases that tests don't cover.

For this to be accepted, the PR has to be modified to only ignore comments that begin a line, and a bunch more tests would be needed to exercise the "failing" cases.

# @return [Array<String>] an array of options parsed from .yardopts
def yardopts(file = options_file)
return [] unless use_yardopts_file
File.read_binary(file).shell_split
contents = File.read_binary(file)
opts = contents.gsub(%r{(#|//).*\n?}, "")
Copy link
Owner

@lsegal lsegal Feb 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're going to need a requirement that comments start at the beginning of the line (incl. optional whitespace), otherwise a valid option like the following will not work:

--title "# a title!"

Or even (awkward but completely valid):

lib/*/*.rb
lib//*.rb

Unfortunately this would be a hard requirement.

I would recommend tests for these edge cases too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm completely for the constraint that this only support comments starting at the beginning of the line.

I'm happy to add more tests -- wanted to get your temperature on this first.

@yardoc.options_file = "test"
@yardoc.run
end

it "ignores .yardopts tokens that are comments" do
optsdata = String.new("--one-file --locale es # --locale en\n// --title not_my_title")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test should not pass, see above. Having "#" as an argument to YARD is completely valid.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another bunch of completely valid examples:

--default-return #read
--query "object.path.include?('#')"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the "handle comments ending a line" functionality as an edge case at the last minute. Didn't think about these -- of course, you're right. Happy to not have this.

@@ -510,10 +510,23 @@ def foo; end
optsdata = String.new("foo bar")
expect(optsdata).to receive(:shell_split)
expect(File).to receive(:read_binary).with("test").and_return(optsdata)
allow(optsdata).to receive(:gsub).and_return(optsdata)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this mocked?

Copy link
Author

@eprothro eprothro Feb 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The optsdata string is frozen in this any many other tests. Since shell split is an extension on String I can't mock there, and I didn't want to couple the test any further (e.g. make it more integrated and lose what we actually care about here, that the string is parsed through shell_split)

@lsegal lsegal force-pushed the master branch 2 times, most recently from 44c07a8 to 112a890 Compare January 7, 2020 04:04
@lsegal lsegal closed this Jun 20, 2020
@lsegal lsegal reopened this Jun 20, 2020
@lsegal lsegal changed the base branch from master to main June 20, 2020 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants