search for: contentcach

I'm using the latest llvm/clang 2.8 releases and am getting EXC_BAD_ACCESS crashes in ContentCache::getBuffer. This happens when I'm printing out errors from a compilation run and iterating over TextDiagnosticBuffer returned errors. When checking the errors, I construct a FullSourceLoc and do: int LineNum = SourceLoc.getInstantiationLineNumber(); int ColNum = SourceLoc.getInstantiationCo...

...ase build SourceManager.cpp: In member function 'void clang::LineTableInfo::clear()': SourceManager.cpp:124: error: 'class llvm::StringMap<unsigned int, llvm::BumpPtrAllocator>' has no member named 'clear' SourceManager.cpp: In member function 'const clang::SrcMgr::ContentCache* clang::SourceManager::getOrCreateContentCache(const clang::FileEntry*)': SourceManager.cpp:367: error: no matching function for call to 'llvm::BumpPtrAllocator::Allocate(int, unsigned int&)' SourceManager.cpp: In member function 'const clang::SrcMgr::ContentCache* clang::Sourc...

...e.g. because we are using a .ll file directly), it would open the file as usual, otherwise it would reuse the registered MemoryBuffer. I see a few downsides of this approach, though. It overlaps a bit with the existing SourceManager in clang which already does some caching work through the clang::ContentCache class. At first the cache seems hard to abstract away as it uses clang::FileEntry and looks pretty tailored for clang needs. Also, assuming that the front end is using a MemoryBuffer may be a too strong requirement, in particular for FE's that are mostly unaware of LLVM except for a final LLV...

...he process for reading mirrored Thoughts? Completely broken approach? Broken order? On a different note, switching to the SourceManager topic - I know enough about SourceManager to be dangerous but not enough to ever claim I would have understood the crazy buffer management that's going on in ContentCache :) So I'd need a lot of help to pry that box open eventually. Currently I'd think that this can be done in a subsequent step after the file system is sorted out, but I might be wrong... Cheers, /Manuel

...4]: Compiling FileManager.cpp for Release build llvm[4]: Compiling IdentifierTable.cpp for Release build llvm[4]: Compiling SourceLocation.cpp for Release build llvm[4]: Compiling SourceManager.cpp for Release build SourceManager.cpp: In member function 'const llvm::MemoryBuffer* clang::SrcMgr::ContentCache::getBuffer(clang::Diagnostic&, const clang::SourceManager&, clang::SourceLocation, bool*) const': SourceManager.cpp:74: error: no matching function for call to 'llvm::MemoryBuffer::getFile(const char*, std::string*, off_t, stat*)' /usr/local/src/llvm-2.7/include/llvm/Support/Me...

...gt; > Thoughts? Completely broken approach? Broken order? > > On a different note, switching to the SourceManager topic - I know > enough about SourceManager to be dangerous but not enough to ever > claim I would have understood the crazy buffer management that's going > on in ContentCache :) So I'd need a lot of help to pry that box open > eventually. Currently I'd think that this can be done in a subsequent > step after the file system is sorted out, but I might be wrong... I'd try away from SourceManager. I would hope that the VFS layer stuff doesn't intera...

...mpletely broken approach? Broken order? >> >> On a different note, switching to the SourceManager topic - I know >> enough about SourceManager to be dangerous but not enough to ever >> claim I would have understood the crazy buffer management that's going >> on in ContentCache :) So I'd need a lot of help to pry that box open >> eventually. Currently I'd think that this can be done in a subsequent >> step after the file system is sorted out, but I might be wrong... > > I'd try away from SourceManager. I would hope that the VFS layer stuff...

...roach? Broken order? >>> >>> On a different note, switching to the SourceManager topic - I know >>> enough about SourceManager to be dangerous but not enough to ever >>> claim I would have understood the crazy buffer management that's going >>> on in ContentCache :) So I'd need a lot of help to pry that box open >>> eventually. Currently I'd think that this can be done in a subsequent >>> step after the file system is sorted out, but I might be wrong... >> >> I'd try away from SourceManager. I would hope that the V...

...gt; > Thoughts? Completely broken approach? Broken order? > > On a different note, switching to the SourceManager topic - I know > enough about SourceManager to be dangerous but not enough to ever > claim I would have understood the crazy buffer management that's going > on in ContentCache :) So I'd need a lot of help to pry that box open > eventually. Currently I'd think that this can be done in a subsequent > step after the file system is sorted out, but I might be wrong... > > Cheers, > /Manuel Just for some background about why we have PathV2. In my ques...

...ompletely broken approach? Broken order? >> >> On a different note, switching to the SourceManager topic - I know >> enough about SourceManager to be dangerous but not enough to ever >> claim I would have understood the crazy buffer management that's going >> on in ContentCache :) So I'd need a lot of help to pry that box open >> eventually. Currently I'd think that this can be done in a subsequent >> step after the file system is sorted out, but I might be wrong... >> >> Cheers, >> /Manuel > > Just for some background about wh...

...roach? Broken order? >>> >>> On a different note, switching to the SourceManager topic - I know >>> enough about SourceManager to be dangerous but not enough to ever >>> claim I would have understood the crazy buffer management that's going >>> on in ContentCache :) So I'd need a lot of help to pry that box open >>> eventually. Currently I'd think that this can be done in a subsequent >>> step after the file system is sorted out, but I might be wrong... >>> >>> Cheers, >>> /Manuel >> >> Just...

...le directly), it would open the file as usual, otherwise it would reuse the registered MemoryBuffer. >> >> I see a few downsides of this approach, though. >> >> It overlaps a bit with the existing SourceManager in clang which already does some caching work through the clang::ContentCache class. At first the cache seems hard to abstract away as it uses clang::FileEntry and looks pretty tailored for clang needs. >> >> Also, assuming that the front end is using a MemoryBuffer may be a too strong requirement, in particular for FE's that are mostly unaware of LLVM excep...

...>>>> >>>> On a different note, switching to the SourceManager topic - I know >>>> enough about SourceManager to be dangerous but not enough to ever >>>> claim I would have understood the crazy buffer management that's going >>>> on in ContentCache :) So I'd need a lot of help to pry that box open >>>> eventually. Currently I'd think that this can be done in a subsequent >>>> step after the file system is sorted out, but I might be wrong... >>>> >>>> Cheers, >>>> /Manuel &gt...

...>>> > >>> On a different note, switching to the SourceManager topic - I know > >>> enough about SourceManager to be dangerous but not enough to ever > >>> claim I would have understood the crazy buffer management that's going > >>> on in ContentCache :) So I'd need a lot of help to pry that box open > >>> eventually. Currently I'd think that this can be done in a subsequent > >>> step after the file system is sorted out, but I might be wrong... > >>> > >>> Cheers, > >>> /Manue...

Hi Manuel, On Nov 28, 2011, at 2:49 AM, Manuel Klimek wrote: > Hi, > > while working on tooling on top of clang/llvm we found the file system > abstractions in clang/llvm to be one of the points that could be nicer > to integrate with. I’m writing this mail to propose a strawman and get > some feedback on what you guys think the right way forward is (or > whether we should

Hi, while working on tooling on top of clang/llvm we found the file system abstractions in clang/llvm to be one of the points that could be nicer to integrate with. I’m writing this mail to propose a strawman and get some feedback on what you guys think the right way forward is (or whether we should just leave things as they are). First, the FileManager we have in clang has helped us a lot for