Skip to content

[move-function] Add tests that show that the debugger displays variables correctly given usage of the move function. #3986

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

Conversation

gottesmm
Copy link

These are the first end to end tests that validate that showing moved variables
works correctly.

They work by just stepping through a program and validating the we can dump variables appropriately given their lifetimes.

…les correctly given usage of the move function.

These are the first end to end tests that validate that showing moved variables
works correctly.
@gottesmm
Copy link
Author

Waiting for swiftlang/swift#41523 to land.

@gottesmm
Copy link
Author

@swift-ci test

@gottesmm gottesmm merged commit eee7d51 into swiftlang:stable/20211026 Feb 23, 2022
@gottesmm gottesmm deleted the stable/20211026/move-function-tests branch February 23, 2022 16:03

# We haven't defined varK yet.
varK = frame.FindVariable('k')
self.assertTrue(varK.value == None, "varK initialized too early?!")

Choose a reason for hiding this comment

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

thank you for the tests!

Note there are many specific assertion functions, including assertIsNone, assertEqual, assertGreater, etc. They help produce better error messages if a test does fail.

Copy link
Author

Choose a reason for hiding this comment

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

Ok. I'll send a follow on commit. I also noticed an fr v that snuck in there that is not necessary.

Choose a reason for hiding this comment

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

I don't want to create work, I mean only to mention it for future.

Copy link
Author

Choose a reason for hiding this comment

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

@kastiglione I had other things I needed to do and it inspired me to port some tests.

threads = lldbutil.get_threads_stopped_at_breakpoint(
self.process, self.breakpoints[0])
self.assertTrue(len(threads) == 1)
self.thread = threads[0]

Choose a reason for hiding this comment

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

You might be able to achieve the same with

        target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
            self, 'stop here', lldb.SBFileSpec('main.swift'))
       self.assertGreater(bkpt.GetNumLocations(), 6)


# Go to the last breakpoint and make sure that k is reinitialized
# properly.
self.runCmd('continue')

Choose a reason for hiding this comment

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

if you store the process above, you could do process.Continue() here, which is slightly nicer than parsing a string command.


# Go to breakpoint 3. k should no longer be valid.
self.runCmd('continue')
self.assertTrue(varK.value == None, "K is live but was moved?!")

Choose a reason for hiding this comment

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

self.assertEqual() will print the value the the comparison fails for easier debugging.

see lldb/third_party/Python/module/unittest2/unittest2/case.py for a full list

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.

3 participants