-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Get rid of "unused variable" warnings #31876
Conversation
This is most likey a leftover from 24d10ad and can go.
Pinging @elastic/es-core-infra |
@@ -130,7 +130,8 @@ public int getMaxLoopCounter() { | |||
private final ScriptClassInfo scriptClassInfo; | |||
private final CompilerSettings settings; | |||
private final String name; | |||
private final String source; | |||
// TODO can this be removed all up the call chain? | |||
// private final String source; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdconrad I couldn't find any reference to this field, but maybe its here for debugging purposes or anything the like? In that case I would add a comment instead of removing. If this is really unused, maybe it can also be removed from the method signatures passing it down here. Could you take a look and comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will take a look! Thanks for pointing this out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbuescher Looks like this is now extraneous. It never got removed once source was set in the class above. Please feel free to remove this as part of this PR or if you'd prefer I can remove it in a different PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do, thanks
Request replicaRequest = (Request) primary.perform(request).replicaRequest; | ||
// TODO check if the following two lines are really unused or might have side effects | ||
// final Request request = new Request(); | ||
// Request replicaRequest = (Request) primary.perform(request).replicaRequest; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ywelsch replicaRequest was used to test the primaryTerm() with "assertThat(replicaRequest.primaryTerm(), equalTo(primaryTerm));". Since that got removed, this part of the test can also go I guess. Does the test still perform its function after this? After all the primaryTerm gets mocked out somewhere above, but never asserted anywhere later? Could you take a look and comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can delete this test. It doesn't do anything meaningful.
...est-high-level/src/test/java/org/elasticsearch/client/documentation/CRUDDocumentationIT.java
Show resolved
Hide resolved
Currently Role.Builder keeps a reference to the FieldPermissionsCache that is passed into its constructors. This seems to be unused except for passing it on to convertFromIndicesPrivileges() in the second ctor itself, but we don't need to keep the internal reference in that case, so it can be removed. Relates to elastic#31876
Currently Role.Builder keeps a reference to the FieldPermissionsCache that is passed into its constructors. This seems to be unused except for passing it on to convertFromIndicesPrivileges() in the second ctor itself, but we don't need to keep the internal reference in that case, so it can be removed. Relates to #31876
All the open questions are adressed now, I think this is ready for a full review now. Spin off in #31935 can be merged separately but is also included in this PR. |
Conflicts: client/rest-high-level/src/test/java/org/elasticsearch/client/documentation/SnapshotClientDocumentationIT.java server/src/test/java/org/elasticsearch/index/query/GeoDistanceQueryBuilderTests.java x-pack/plugin/rollup/src/test/java/org/elasticsearch/xpack/rollup/RollupRequestTranslationTests.java
d42f896
to
ff0d7f4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating the PR. I left a couple of comments.
libs/x-content/src/test/java/org/elasticsearch/common/xcontent/ObjectParserTests.java
Show resolved
Hide resolved
...s/analysis-common/src/main/java/org/elasticsearch/analysis/common/KeepWordFilterFactory.java
Show resolved
Hide resolved
final Set<String> articleIds = new HashSet<>(); | ||
final Set<String> commentIds = new HashSet<>(); | ||
final Map<String, Set<String>> commenterToCommentId = new HashMap<>(); | ||
|
||
private Control(String category) { | ||
this.category = category; | ||
// category not used any further |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to remove the constructor argument then as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, makes sense to remove the whole constructor actually since the class is private already and only used inside this test class.
} | ||
|
||
void update(String word, String topField, float score, float idf, int docFreq, int tf) { | ||
public void update(String word, String topField, float score) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to increase the visibility of this method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not sure how this happend. Removing.
test/framework/src/main/java/org/elasticsearch/test/store/MockFSDirectoryService.java
Show resolved
Hide resolved
x-pack/plugin/sql/src/main/java/org/elasticsearch/xpack/sql/parser/LogicalPlanBuilder.java
Show resolved
Hide resolved
@@ -64,6 +64,7 @@ public void testLimit() { | |||
SearchSourceBuilder sourceBuilder = SourceGenerator.sourceBuilder(container, null, randomIntBetween(1, 10)); | |||
Builder aggBuilder = sourceBuilder.aggregations(); | |||
assertEquals(1, aggBuilder.count()); | |||
@SuppressWarnings("unused") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether we should provide an accessor instead and uncomment the line below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
...r/src/main/java/org/elasticsearch/xpack/watcher/notification/pagerduty/PagerDutyAccount.java
Show resolved
Hide resolved
...r/src/test/java/org/elasticsearch/xpack/watcher/test/AbstractWatcherIntegrationTestCase.java
Show resolved
Hide resolved
@danielmitterdorfer thanks a lot for getting back to this. I addressed most of your comments with the latest commit, checking back on how MovAvgIT is supposed to work. Could you go through the other comments I replied to and see if you agree? |
parseQuery(query).toQuery(createShardContext()); | ||
// TODO: what can we check? | ||
// TODO: what can we check? See https://github.com/elastic/elasticsearch/issues/34043 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating the issue!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @cbuescher! LGTM
@cbuescher I think this change caused some failures I am hitting locally. It reproduces on master:
|
I opened #34098 |
This change cleans up "unused variable" warnings. There are several cases were we most likely want to suppress the warnings (especially in the client documentation test where the snippets contain many unused variables). In a lot of cases the unused variables can just be deleted though.
Another clean up trying to get rid of some annoying warnings. One large group that is
reasonably easy to tackle is the "unused variable" warnings. There are several cases
were most likely want to suppress the warnings (especially in the client documentation test
where the snippets should contain unused variable names). Most of the things can just be deleted though.