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

Fix backtrace line numbers following macros #30011

Merged
merged 1 commit into from
Nov 17, 2018
Merged

Conversation

tkluck
Copy link
Contributor

@tkluck tkluck commented Nov 12, 2018

This is an attempt at fixing #28618 .

The CodeInfo block has a field codelocs that indexes into an array with full LineInfoNode objects. This data model allows de-duplication, and in practice it does (only) uniq-style deduplication, i.e. only consecutive equal objects are deduplicated by this scheme.

The lambda compact-ir generates this structure. This commit fixes a bug where it mixes monotonously increasing the indices (for codeloc) with push/pop operations. This is wrong because the latest LineInfoNode object is always at the end of the current size of the array; not one position after the current LineInfoNode.

I have only tested my small test case as described in that bug report; I haven't run the full test suite and I also have only tested this patch on top of release-1.0; not on top of master. Just sending this out there hoping that others can spot any issues with my code asap.

The `CodeInfo` block has a field `codelocs` that indexes into an array
with full `LineInfoNode` objects. This data model allows de-duplication,
and in practice it does (only) `uniq`-style deduplication, i.e. only
consecutive equal objects are deduplicated by this scheme.

The lambda `compact-ir` generates this structure. This commit fixes a bug
where it mixes monotonously increasing the indices (for `codeloc`) with
push/pop operations. This is wrong because the latest `LineInfoNode`
object is always at the end of the current size of the array; not
one position after the current `LineInfoNode`.
@tkluck
Copy link
Contributor Author

tkluck commented Nov 13, 2018

CI issues look unrelated; they seem related to type inference and only appear on the non-x86 architecture, which also take to be indicative of "unrelated to this PR".

 return type Int128 does not match inferred return type Any

I think this PR is probably ready to go into master and into 1.0.x.

@fredrikekre fredrikekre added bugfix This change fixes an existing bug macros @macros backport pending 1.0 labels Nov 13, 2018
@StefanKarpinski
Copy link
Member

Yes, that error is #29923, which is a real pain and not really "intermittent" anymore.

@fredrikekre fredrikekre reopened this Nov 16, 2018
@vchuravy vchuravy merged commit 8c5baf3 into JuliaLang:master Nov 17, 2018
@KristofferC KristofferC mentioned this pull request Nov 19, 2018
61 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug macros @macros
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants