Deprecate other_locations in analyzer spec, to clarify vs. trace #66
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It appears that #20 intended to remove
other_locations
as superseded bytrace
, but it left the old entry (only) in the example JSON object. An expanded section describingother_locations
was put back in #57, that issue thread asserts that it is still valid and in use by Code Climate's duplication engine.These two fields certainly seem functionally redundant, hence the confusion in #56, which I shared too.
Under assumption that both are used/accepted in implementations of the current version of the spec, this change restores presence of both in the reference but proposes deprecating
other_locations
and hence de-emphasizes its documentation (Trace
objects are already specified in detail).The spec version was 0.3.1 as of #57, and still is now.