Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-12-23T09:38:25+00:00 2019-12-23T09:38:25+00:00 Raphael Isemann teemperor@gmail.com 2019-12-23T09:38:12+00:00 urn:sha1:5dca0596a959217a1c18858a62ed35245a4c42b4 Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630 2019-08-22T07:41:23+00:00 Raphael Isemann teemperor@gmail.com 2019-08-22T07:41:23+00:00 urn:sha1:ae34ed2c0d2fba36d8363ba7fffc1dbe18878335 Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624 2019-05-06T20:01:21+00:00 Greg Clayton clayborg@gmail.com 2019-05-06T20:01:21+00:00 urn:sha1:8a7779209d93660d2fb68f1f5ebe1d56959495b8 Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071 2019-04-01T22:03:04+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-04-01T22:03:04+00:00 urn:sha1:dd245c4f8fe0e2c1222fd0360a7febc752db9417 This patch removes spurious links against Python. llvm-svn: 357431 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2018-12-04T17:58:21+00:00 Jonas Devlieghere jonas@devlieghere.com 2018-12-04T17:58:21+00:00 urn:sha1:edaf2bcc77c730739d90493865f1a90fb377b34d Make use of the convenience helpers from FileSystem. Differential revision: https://reviews.llvm.org/D55240 llvm-svn: 348287 2018-11-09T01:59:28+00:00 Jonas Devlieghere jonas@devlieghere.com 2018-11-09T01:59:28+00:00 urn:sha1:72787ac661626c6972bf028dfb9b3615a89346ea The whole point of this change was making it possible to resolve paths without depending on the FileSystem, which is not what I did here. Not sure what I was thinking... llvm-svn: 346466 2018-11-09T00:50:50+00:00 Jonas Devlieghere jonas@devlieghere.com 2018-11-09T00:50:50+00:00 urn:sha1:9560f353ed86e556154629dec072671e6050c12d In order to call real_path from the TildeExpressionResolver we need access to the FileSystem. Since the resolver lives under utility we have to pass in the FS. llvm-svn: 346457 2018-09-04T23:09:49+00:00 Frederic Riss friss@apple.com 2018-09-04T23:09:49+00:00 urn:sha1:412f24dd2d987973b0b3be40957574e682bf1530 TestCompletion was failing quite frequently on our Linux bots. Some tracing revealed that when we are iterating BaseDir we are not getting all the entries. More specifically, we are sometimes missing the entry corresponding to the TestCompletion directory that the first test in DirCompletionAbsolute is looking for. BaseDir is the directory where lit is creating all the temporary files. The semantics of opendir/readdir are unclear when it comes to iterating over a directory that changes contents, but it seems like on Linux you might fail to list an entry even if it was there before opendir and is still present throughout the iteration. Changing the test to only look inside of the test- specific directory seems to fix the instability. This commit also removes some assertions that were added to try to track down this issue. llvm-svn: 341425 2018-08-31T23:03:28+00:00 Frederic Riss friss@apple.com 2018-08-31T23:03:28+00:00 urn:sha1:78a10a7a9bb2d56a10dabae58ebd488055b1d828 If you tried to complete somwthing like ~/., lldb would come up with a lot of non-existent filenames by concatenating every exisitng file in the directory with an initial '.'. This was due to a workaround for an llvm::fs::path::filename behavior that was not applied selectively enough. llvm-svn: 341268