Skip to content

Add trace #20

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

Merged
merged 1 commit into from
Nov 2, 2015
Merged

Add trace #20

merged 1 commit into from
Nov 2, 2015

Conversation

mrb
Copy link
Contributor

@mrb mrb commented Oct 9, 2015

Traces! /c @brynary

@mrb
Copy link
Contributor Author

mrb commented Oct 21, 2015

ping @brynary

Some engines require the ability to refer to other source locations in describing an issue. For this reason, an `Issue` object can have an associated `Trace`, a data structure meant to represent ordered or unordered lists of source code locations. A `Trace` has the following fields:

* `locations` -- **[Location] - Required**. An array of `Location` objects.
* `stacktrace` -- **Boolean - Optional**. When `true`, this `Trace` object will be treated like an ordered stacktrace by the CLI and the Code Climate UI.
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 want to specify what order the stacktrace is to be interpreted in? Python outputs stack traces in reverse order from most languages, for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pbrisbin When you say that a trace is a stacktrace, we'll treat it as an ordered Array, so it's up to the engine to provide it in the order that it should be displayed.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK, so if some Python engine shows it one way and some Ruby engine another, we don't care to normalize that, whatever it is it is? Seems fine to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pbrisbin Yes I think that's correct.

@brynary
Copy link
Member

brynary commented Oct 22, 2015

Clarify default for stacktrace is false and then we can merge

@mrb mrb merged commit 0576826 into master Nov 2, 2015
@dblandin dblandin deleted the traces branch March 15, 2017 15:06
ches added a commit to ches/platform that referenced this pull request Sep 18, 2021
It appears that codeclimate#20 intended to remove `other_locations` as superseded
by `trace`, but it left the old entry (only) in the example JSON object.
An expanded section describing `other_locations` was put back in codeclimate#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 codeclimate#56.

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.
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.

4 participants