Details
- Reviewers
a.sidorin shafik a_sidorin martong - Commits
- rG94049554166c: [PR40778] Preserve addr space in Derived to Base cast.
rL355606: [PR40778] Preserve addr space in Derived to Base cast.
rC355606: [PR40778] Preserve addr space in Derived to Base cast.
rGe2ddb2ad1d84: [ASTImporter] Changed use of Import to Import_New in ASTImporter.
rL355598: [ASTImporter] Changed use of Import to Import_New in ASTImporter.
rC355598: [ASTImporter] Changed use of Import to Import_New in ASTImporter.
rGdeaf7ab810a2: [ASTImporter] Changed use of Import to Import_New in ASTImporter.
rC347752: [ASTImporter] Changed use of Import to Import_New in ASTImporter.
rL347752: [ASTImporter] Changed use of Import to Import_New in ASTImporter.
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 24290 Build 24289: arc lint + arc unit
Event Timeline
The Import functions are replaced by Import_New and error handling is added. This is done in the implementation of the Import_New functions itself, and in importInto. (Code of old Import functions is moved to the Import_New and updated to use Import_New.) Some other functions in ASTImporter are still using the Import, these are to be changed later.
Hi Balasz,
As I guess, the next step is to convert all Importcalls to Import_New and then rename Import_New into Import. If so, why aren't we able to just change the behaviour of Import methods?
Also, there are some comments inline (review is not fully completed, I'll continue review after we agree if this patch is needed).
include/clang/AST/ASTImporter.h | ||
---|---|---|
192–198 | an import error? | |
198 | these versions | |
lib/AST/ASTImporter.cpp | ||
7890 | We can use Import_New if we change this code, like it is done below. | |
7919 | We can use -> here. Same in some cases below. | |
7920 | If the true branch is enclosed with braces, the else branch should be enclosed as well. | |
7934–7935 | This line exceeds 80-char limit. |
If we change signature of Import now, other parts of the code (in clang and LLDB) would not compile (without changing to use the new kind of Import). If there is a Import_New the old code can still compile and can be changed later.
lib/AST/ASTImporter.cpp | ||
---|---|---|
7890 | For IdentifierInfo there is no Import_New because this is the one kind of import that can not fail, it remains the same Import as before (does not return Expected). |
include/clang/AST/ASTImporter.h | ||
---|---|---|
192–198 | I do not know what is the correct, but a specific import error is returned, that occurred during the import. | |
198 | If the other comment is changed I can change this too, but alone this is not worth it. This is anyway a temporary comment, and if the first Import there is removed the second can not compile anyway (and the Import_New will be the Import later). |
Hi Alexei,
Could you please also take a look on that patch which this one depends on? https://reviews.llvm.org/D53751
I think the changes of that patch are included in this one too. Thank you.
I reverted this change because it breaks a bunch of lldb tests (on MacOS, and probably on other platforms too).
To be clear, part of the reason I'm reacting strongly here is that this is not the first patch this has come up on.
I'm worried about the broader trend of landing patches to ASTImporter without proper reviews and testing as I am of this very instance.
I really think you should consider asking reviews to somebody who's familiar with clang and test lldb as it's the main client of this functionality we have in tree.
I reverted this change because it breaks a bunch of lldb tests (on MacOS, and probably on other platforms too). To be clear, part of the reason I'm reacting strongly here is that this is not the first patch this has come up on. I'm worried about the broader trend of landing patches to ASTImporter without proper reviews and testing as I am of this very instance. I really think you should consider asking reviews to somebody who's familiar with clang and test lldb as it's the main client of this functionality we have in tree.
@davide I am terribly sorry about this issue. I just applied this patch on my Linux box, and it did not failed those tests which failed on the green lab buildbots. Could you please refer to the Linux buildbots which failed? Seems like there is a significant difference between the testsuites on Linux and MacOS. Our primary target is Linux and we do run the LLDB tests before we accept any commit into our fork and only then we continue with upstreaming to Phabricator.
Our platform in our CI is Linux only, but we are in the middle of getting a hosted MacOS to support our CI. I do hope that in the near future there will be no such issues. In the meantime, is there a way for us to execute a green lab MacOS build bot with a specific patch before a commit? If that is not possible, then we can just promise that we will monitor your buildbots and we will do the revert.
I have no Linux bots access, this fails on macos (looks on http://lab.llvm.org:8080/green/). Although now it's too late because the logs are gone.
Our platform in our CI is Linux only, but we are in the middle of getting a hosted MacOS to support our CI. I do hope that in the near future there will be no such issues. In the meantime, is there a way for us to execute a green lab MacOS build bot with a specific patch before a commit? If that is not possible, then we can just promise that we will monitor your buildbots and we will do the revert.
I'm not aware of a way of pre-commit testing this hosted on llvm.org. I generally run on my machine and check the bots output.
an import error?