On Windows allows setting breakpoint at path with different case (file main.c, breakpoint at Main.c).
fixes http://llvm.org/pr22667
Details
Diff Detail
Event Timeline
This probably seems like a lot of comments, but most of them are pretty minor. Overall this looks like a good patch. When running the test suite with this patch, did any tests start showing up as Unexpected Success?
packages/Python/lldbsuite/test/dotest.py | ||
---|---|---|
288–294 | See if you can get PTVS to work. If so, you won't need any of this code and it will be a much better debugging experience anyway. Assuming PTVS works for you, I'd rather just delete this code. I'm planning to add info about using PTVS to the website this week. | |
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_case_sensitivity/TestBreakpointCaseSensitivity.py | ||
21 | When we run the test suite, it's going to report this test as test_case_sensitivity_breakpoint. So looking at it, you will have to think for a minute about whether the test was expecting it to match or to not match. It would be nice if the test was called something like test_breakpoint_matches_file_with_different_case. So then you would need 2 test methods. One for matching with different case, and one for not matching with different case. Then you could use a decorator to enable them on windows or on not windows. Like this: @skipIf(oslist=no_match(['windows'])) # Skip for non-windows platforms def test_breakpoint_matches_file_with_different_case(self): self.build() self.case_sensitivity_breakpoint(true) @skipIf(oslist=['windows']) # Skip for windows platforms def test_breakpoint_doesnt_match_file_with_different_case(self): self.build() self.case_sensitivity_breakpoint(false) | |
26–36 | Then this whole thing becomes: def case_sensitivity_breakpoint(self, case_insensitive): exe = "a.out" if case_insensitive: exe = strupper(exe) exe = os.path.join(os.getcwd(), exe) | |
93–96 | If should_hit is false, then I think we should launch the process anyway, but verify that it DOES NOT get hit. It would look something like this (not tested, maybe some errors here): process = self.target.LaunchSimple(None, None, self.get_process_working_directory()) self.assertTrue(process, PROCESS_IS_VALID + desc) if should_hit: # Did we hit our breakpoint? from lldbsuite.test.lldbutil import get_threads_stopped_at_breakpoint threads = get_threads_stopped_at_breakpoint (process, breakpoint) self.assertEqual(1, len(threads), "There should be a thread stopped at breakpoint" + desc) # The hit count for the breakpoint should be 1. self.assertEqual(1, breakpoint.GetHitCount()) else: self.assertEqual(lldb.eStateExited, process.GetState()) | |
104 | Minor nitpick, but can you use assertEqual here? Same goes for following test. This will provide a better error message, since as the code is written here it will just say "Expected True, got False", but with assertEqual, it will say "expected 1, got 0" or something like that. | |
109 | process.Kill() is kind of harsh. I know some tests do it, but usually we just do process.Continue() to let it exit gracefully. (It shouldn't matter in practice, so whatever you prefer) | |
110 | Need newline at end of file. | |
110 | This line is harmless, but not necessary. Because the test runner should end up deleting the target later anyway. | |
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_case_sensitivity/main.c | ||
7 | Doesn't look like this is clang-formatted. We don't use a space between function name and open parentheses. You'll see a lot of code that does this, but after that code was written we agreed to remove the parentheses. clang-format should remove it for you automatically. | |
source/Core/ConstString.cpp | ||
269 | Looks like this code also isn't clang-formatted. If you build clang-format (with ninja clang-format) and add its folder to your PATH environment variable, then when your changes are staged in git, just run git clang-format. If you've already committed you can uncommit with git reset --soft HEAD. Then they will be staged again, then you can run git clang-format, then re-add all the modified files, and then recommit. | |
274–275 | I thought this was wrong at first, but then I realized it's right. Can you add a comment above this line: // Since the pointers weren't equal, and identical ConstStrings always have identical pointers, the result must be false. | |
source/Host/common/FileSpec.cpp | ||
400 | There is a minor edge case that isn't handled here, when *this and rhs have different syntaxes. Granted if that's ever the case, it's very unlikely that the FileSpecs would be otherwise the same, but it's possible (especially if m_directory is not set). So I think we should add a method to FileSpec bool IsCaseSensitive() const { return m_syntax != ePathSyntaxWindows; } Then this line becomes: const bool case_sensitive = IsCaseSensitive() || rhs.IsCaseSensitive(); Here the comparison should be case sensitive if *either* FileSpec requires a case sensitive comparison, not just *this. | |
402 | Can you reverse this conditional and just early out if they don't match (I know that wasn't your code, but seems to fit more with LLVM style. | |
522 | If you add the IsCaseSensitive() method, then this would change here too (and also you should check a and b just like I mentioned in the last comment. Same goes for the rest of the places. |
source/Core/ConstString.cpp | ||
---|---|---|
269 | Or, you can use git clang-format rev to format all changes since rev (you probably want rev=HEAD^). </drive-by> |
source/Core/ConstString.cpp | ||
---|---|---|
269 | Neat, didn't know about this. (although on Windows you have to use either HEAD~1 or HEAD^^, since ^ needs to be escaped. This makes it particularly annoying if you want HEAD~2 for example, because then you need HEAD^^^^, etc. So most people on windows use the ~n syntax. |
packages/Python/lldbsuite/test/dotest.py | ||
---|---|---|
288–294 | Ok I removed this part, it is working using PTVS. But maybe in future we will still need something similar if we would like to debug lldb testsuite using lldb, because I don't know whether lldb will support Python in near future. We can always return this part back. |
source/Host/common/FileSpec.cpp | ||
---|---|---|
519 | Did the case sensitive check get removed here? I thought this would need to be result = ConstString::Compare(a.m_directory, b.m_directory, a.IsCaseSensitive() || b.IsCaseSensitive()); The same later in this function, and also for FileSpec::Equal |
Looks good after the fix of the misspelling. If you want I can fix it for you and commit tomorrow.
I assume you ran the test suite and did not see any new errors?
source/Host/common/FileSpec.cpp | ||
---|---|---|
535 | Minor nitpick, you misspelled case_sensitive as case_sentitive. |
The testsuite passed the same way as master, but no UNEXPECTED SUCCESS.
Please fix the miss spelling directly.
Thanks.
source/Host/common/FileSpec.cpp | ||
---|---|---|
517 | I don't know what check you mean. bool case_sensitive is the check here. |
Sorry that comment was a mistake. When you uploaded the most recent diff,
did you generate the diff against your first patch? Or against tip of
trunk? I think you may have generated it against your first patch, but
Phabricator gets confused and shows the wrong thing in that case.
It should be fine for me to download it and apply this way, but it makes it
harder to review. So in the future always generated all versions of your
diff against the same base.
I have generated it against master branch. I used git reset HEAD~1, modified, commited and created patch.
Maybe the problem was I used the Arcanist for the first diff and then I used web interface, as you have suggested.
Ahh that could be. In any case when i view the full diff it looks ok. I'll
commit later today, thanks!
The non-Windows version of the test actually fails for some reason. I think it's more likely to be a probelm in the test and not in the C++ side of the patch, but I'm not sure. Do you by any chance have a Linux box to test on? (It's not a big problem if you don't, I've xfail'ed the test on Linux in the meantime)
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/11757/steps/test1/logs/stdio
There's the logs for the test that failed.
See if you can get PTVS to work. If so, you won't need any of this code and it will be a much better debugging experience anyway. Assuming PTVS works for you, I'd rather just delete this code. I'm planning to add info about using PTVS to the website this week.