-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[cxxmodules] Add initial implementation of the semantic GMI. #5094
[cxxmodules] Add initial implementation of the semantic GMI. #5094
Conversation
Starting build on |
Build failed on ROOT-fedora27/noimt. Failing tests: |
Build failed on ROOT-fedora29/python3. Failing tests: |
Build failed on ROOT-ubuntu18.04-i386/cxx14. Failing tests: |
@phsft-bot build! |
Starting build on |
Build failed on ROOT-fedora31/noimt. Failing tests: |
Build failed on ROOT-fedora29/python3. Failing tests: |
Build failed on ROOT-performance-centos7-multicore/default. Failing tests: |
Build failed on ROOT-debian10-i386/cxx14. Failing tests: |
Starting build on |
Build failed on ROOT-fedora31/noimt. Failing tests: |
Build failed on ROOT-fedora29/python3. Failing tests: |
Build failed on ROOT-debian10-i386/cxx14. Failing tests: |
fd9cca9
to
a7869de
Compare
Starting build on |
Build failed on ROOT-fedora31/noimt. Failing tests: |
Build failed on ROOT-fedora29/python3. Failing tests: |
Build failed on ROOT-performance-centos7-multicore/default. Failing tests: |
Build failed on ROOT-debian10-i386/cxx14. Failing tests: |
We seem to fail to generate the dtor of Minimal reproducer:
|
Build failed on ROOT-fedora31/noimt. Failing tests: |
Build failed on ROOT-performance-centos7-multicore/default. Failing tests:
|
Build failed on ROOT-fedora30/cxx14. Failing tests:
|
ce22a8f
to
41189a1
Compare
Starting build on |
41189a1
to
1ac186c
Compare
Starting build on |
@phsft-bot build with flags -DCTEST_TEST_EXCLUDE_NONE=On |
Starting build on |
Build failed on ROOT-performance-centos7-multicore/default. Failing tests:
|
Those fail all over the place. |
} else if (NamespaceDecl *NSD = llvm::dyn_cast<NamespaceDecl>(R)) | ||
Register(NSD, /*AddSingleEntry=*/ false); | ||
else if (TypedefNameDecl *TND = dyn_cast<TypedefNameDecl>(R)) | ||
Register(TND); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't typedef decl be repeated (in several header files and thus several modules)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but it should define the same entity, otherwise modules ODR hash will complain. So whichever we pick should be fine. I suspect that may lead to loading the 'wrong' module to resolve the intended typedef but cannot do anything better.
Alternatively, we could load all modules which have this typedef name -- that would be redundant because if the typedefs are all the same what's the point; if the typedefs are different we will get an ODR violation diagnostic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to load the pcm for the target of the typedef?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we need to load something that has a clang::Decl for the missing identifier
// ... unless it's a .pcm.lock file, which indicates that someone is | ||
// in the process of rebuilding a module. They'll rebuild the index | ||
// at the end of that translation unit, so we don't have to. | ||
if (llvm::sys::path::extension(D->path()) == ".pcm.lock") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens in the follow scenario:
(1) Process A starts and build a module and thus creates a .pcm.lock
(2) Process A is put to sleep (and/or is very very slow)
(3) some other pcm is created fully (and have names such it is early in the directory iteration).
(4) Process B starts and try to write the index and gives ups
(5) Process B finishes
(6) Process A wakes ups and finish write the module.idx.
Are the extra pcm creates in step (3) included in the module.idx (create by Process A)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will not add it in the index probably.
Note that this is pre-existing llvm code and the ROOT GMI does not actually use it. It provides a table with ExternalIDs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will not add it in the index probably.
I see. Then the comment is not appropriate for our use case [And the result is (silently) sub-optimal, isn't it?]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Let’s see if this will improve when we upgrade llvm.
1ac186c
to
6c26e5f
Compare
Starting build on |
Build failed on ROOT-performance-centos7-multicore/default. Failing tests:
|
Build failed on ROOT-fedora31/noimt. Errors:
|
@phsft-bot build with flags -DCTEST_TEST_EXCLUDE_NONE=On |
No description provided.