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

Nomenclature fixes and some TODO cleanup #856

Merged
merged 1 commit into from
Sep 6, 2017

Conversation

whisperity
Copy link
Contributor

@whisperity whisperity commented Aug 31, 2017

Implements parts of #745 and related issues.

For now, I've added many comments so we can individually see the changes. Of course this can be squashed later.

@whisperity whisperity added enhancement 🌟 WARN ⚠️: Backward compatibility breaker! MIND THE GAP! Merging this patch will mess up compatibility with the previous releases! labels Aug 31, 2017
@whisperity whisperity added this to the 6.0 pre4 milestone Aug 31, 2017
@whisperity whisperity added the WIP 💣 Work In Progress label Aug 31, 2017
@whisperity whisperity changed the title Nomenclature fixes Nomenclature fixes and TODO cleanup Aug 31, 2017
@whisperity whisperity requested a review from gyorb August 31, 2017 16:28
@whisperity whisperity changed the title Nomenclature fixes and TODO cleanup Nomenclature fixes and some TODO cleanup Aug 31, 2017
@whisperity whisperity added API change 📄 Content of patch changes API! CLI 💻 Related to the command-line interface, such as the cmd, store, etc. commands database 🗄️ Issues related to the database schema. labels Aug 31, 2017
@whisperity whisperity force-pushed the nomenclature branch 2 times, most recently from dc446db to 9fc6237 Compare August 31, 2017 19:28
Copy link
Contributor

@Xazax-hun Xazax-hun left a comment

Choose a reason for hiding this comment

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

Nice work! Most of my comments related to possible additional cleanups. Only a few questions for these changes.

@@ -21,58 +21,55 @@ const string API_VERSION = '6.0'
const i64 MAX_QUERY_SIZE = 500
//=================================================

//-----------------------------------------------------------------------------
struct RunData{
struct RunData {
1: i64 runId, // unique id of the run
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we could adopt the convention of having full sentences in comments to comply with the rest of the codebase as the part of this revamp?

9: shared.Severity severity // checker severity
10: ReviewData review // bug review status informations.
struct ReportData {
1: string checkerId, // the qualified id of the checker that reported this
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe this should be renamed as this is the name of the check.

7: i64 line, // line number or the reports main section (not part of the path)
8: i64 column, // column number of the report main section (not part of the path)
9: shared.Severity severity // checker severity
10: ReviewData review // bug review status informations.
Copy link
Contributor

Choose a reason for hiding this comment

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

I would prefer to call this reviewStatus.

struct ReportData {
1: string checkerId, // the qualified id of the checker that reported this
2: string bugHash, // This is unique id of the concrete report.
3: string checkedFile, // this is a filepath
Copy link
Contributor

Choose a reason for hiding this comment

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

In case this is the main file which was given for the analyzer, we should use the same nomenclature.

@@ -93,7 +90,7 @@ typedef list<ReportFilter> ReportFilterList
* Members of this struct are interpreted in "OR" relation with each other.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this comment is very confusing. Both sentences referring to the members of the struct. Is this correct?
Why do we need the v1? Can we remove that now?

Copy link
Contributor

Choose a reason for hiding this comment

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

As a side note, I am not sure this has the same expressivity as the old version.

E.g. how do you represent:

(filepath == A AND checkerName == B) OR (severity == C and reviewStatus == D)

Note that the old format was basically a disjunctive normal form, so we could be sure that every predicate could be translated to that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

v1 can only be removed if the command-line client is upgraded to use the same, new, "v2" filtering semantics.

(filepath == A AND checkerName == B) OR (severity == C and reviewStatus == D)
This kind of filter was not explicable by any of the clients in the v1 version either, even if the API -- if directly called -- seemed to had supported that.

@gyorb, @csordasmarton rewrote the filtering system.

Copy link
Contributor

Choose a reason for hiding this comment

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

The old ReportFilter will be removed.

required=False,
default=argparse.SUPPRESS,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To not have (default: False) printed for the help message in every argument if the argument is already a boolean, and its help already makes it apparent that "it does something if given, otherwise it does not do something ".

)
# Some arguments don't have default values.
# We can't set these keys to None because it would result in an error
# after the call.
args_to_update = ['skipfile',
'analyzers',
'add_compiler_defaults',
Copy link
Contributor

Choose a reason for hiding this comment

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

Why can't this have a default value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As above. Boolean options' help messages usually look better if default: False is not given. The code behaves in a way that if it is not passed, it is considered False.

@@ -322,14 +318,14 @@ def __update_if_key_exists(source, target, key):
output_path=workspace,
output_format='plist',
clean=True,
jobs=args.jobs,
add_compiler_defaults=args.add_compiler_defaults
jobs=args.jobs
)
# Some arguments don't have default values.
# We can't set these keys to None because it would result in an error
# after the call.
args_to_update = ['skipfile',
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this list is replicated. In the future, it might be better to refactor it in a way that this list is created together with the arg parsers.

1: i64 runId, // unique id of the run
2: string runDate, // date of the run
3: string name, // human readable name of the run
4: i64 duration, // duration of the run; -1 if not finished
5: i64 resultCount, // number of results in the run
6: string runCmd, // the used check command
7: optional bool can_delete // true if codeCheckerDBAccess::removeRunResults()
7: optional bool canDelete, // true if codeCheckerDBAccess::removeRunResults()
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we still need the canDelete? I'm not sure we use it in the database with the new schema.

@@ -93,7 +90,7 @@ typedef list<ReportFilter> ReportFilterList
* Members of this struct are interpreted in "OR" relation with each other.
Copy link
Contributor

Choose a reason for hiding this comment

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

The old ReportFilter will be removed.

@whisperity
Copy link
Contributor Author

If everything is fine, I'll squash these commits! Don't merge beforehand.

 - The 'plist' command which was undocumented for a few releases now has
   been removed permanently.
 - Argument list and help of many commands have been made better
 - The "old-style" 'checkers' command is dropped in favour of the new
   one introduced back in 5.8.
 - Most 'cmd' subcommands take run-name as a positional argument, rather
   than "--name RUN_NAME".
 - Thrift files have been reformatted to a new scheme of comments and
   naming.
Copy link
Contributor

@Xazax-hun Xazax-hun left a comment

Choose a reason for hiding this comment

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

LGTM!

@Xazax-hun Xazax-hun merged commit 94dec68 into Ericsson:master Sep 6, 2017
@whisperity whisperity deleted the nomenclature branch September 14, 2017 07:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API change 📄 Content of patch changes API! CLI 💻 Related to the command-line interface, such as the cmd, store, etc. commands database 🗄️ Issues related to the database schema. enhancement 🌟 WARN ⚠️: Backward compatibility breaker! MIND THE GAP! Merging this patch will mess up compatibility with the previous releases! WIP 💣 Work In Progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants