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

Check when we manually increment stack depth, we correctly decrement it on return #1160

Merged
merged 1 commit into from
Mar 15, 2017

Conversation

ChrisJefferson
Copy link
Contributor

This just adds some more tests for #1151, to check the incrementing and decrementing of stack depth works correctly by doing lots of calls in a loop.

@codecov
Copy link

codecov bot commented Feb 21, 2017

Codecov Report

Merging #1160 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1160   +/-   ##
=======================================
  Coverage   68.36%   68.36%           
=======================================
  Files         435      435           
  Lines      230679   230679           
=======================================
  Hits       157706   157706           
  Misses      72973    72973

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 70e9509...bc7557a. Read the comment docs.

gap> list2 := [1,[1,[1,[1,0]]]];
[ 1, [ 1, [ 1, [ 1, 0 ] ] ] ]

# Check we increment / decrement stack correctly
Copy link
Member

Choose a reason for hiding this comment

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

This is not clear as to what "stack" is meant. I assume this refers to the RecursionDepth variable in the kernel -- I think the comment should say so explicitly.

Also, I think this implicitly relies on the RecursionTrapInterval being "small" enough (right now it is set to 5000). That's fine, but I think I'd mention this, too. E.g.:

# Check that the RecursionDepth counter in the kernel is incremented and
# decremented correctly. If it isn't decremented correctly, then it will
# eventually exceed the `RecursionTrapInterval` (which normally is
# 5000), and the test will fail due to an unexpected error message.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done. Also reduced length of commit message, in case that was coming next.

@fingolfin
Copy link
Member

Perhaps rebase to avoid test fluctuations?

@olexandr-konovalov
Copy link
Member

Has this been rebased? Ready to merge? Suspicious that tests are added, but coverage remains the same.

@ChrisJefferson
Copy link
Contributor Author

I wouldn't expect this to hit any more lines of code, it's just checking if we do something a lot nothing breaks, and coverage doesn't care about number of times a line is executed :)

@fingolfin fingolfin merged commit c171d88 into gap-system:master Mar 15, 2017
@ChrisJefferson ChrisJefferson deleted the test-recurse branch May 12, 2017 11:26
@olexandr-konovalov olexandr-konovalov added the release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes label Jan 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants