search for: sourcemanager

...installing clang.... while llvm installs properly but clang gives this error on invoking make in Clang make[2]: Leaving directory `/home/na2271/Desktop/llvm-2.3-x/tools/clang/lib/Headers' make[2]: Entering directory `/home/na2271/Desktop/llvm-2.3-x/tools/clang/lib/Basic' llvm[2]: Compiling SourceManager.cpp for Release 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 cl...

...e jumps right into the design discussion then. >> >>> Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>> >>>> Pro: >>>> - only one interface for developers to learn on the project (no more >>>> PathV1 vs PathV2 vs FileManager) >>>> - only one implementati...

...right into the design discussion then. >>> >>>> Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>>> >>>>> Pro: >>>>> - only one interface for developers to learn on the project (no more >>>>> PathV1 vs PathV2 vs FileManager) >>>>> - on...

...eat :) /me jumps right into the design discussion then. > >> Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >> >>> Pro: >>> - only one interface for developers to learn on the project (no more >>> PathV1 vs PathV2 vs FileManager) >>> - only one implementation (per-platform) for...

...ase! Great :) /me jumps right into the design discussion then. > Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. > >> Pro: >> - only one interface for developers to learn on the project (no more >> PathV1 vs PathV2 vs FileManager) >> - only one implementation (per-platform) for easier maintenance...

...errors when emitting instructions (basically because the platform has configurable properties with dependencies between instructions and it was easier to check for their interaction late than try to detect them earlier, e.g. through custom encoder methods and tablegen). Emitting diagnostics through SourceManager::PrintMessage() "works" in the limited sense of communicating the problem to a human, however it doesn't prevent generation of an incorrect output file or change the process exit code. We'd prefer not to resort to report_fatal_error() since that isn't a polite way to diagnose...

...Consumer*, bool)' tutorial1.cpp:(.text+0xf4): undefined reference to `clang::LangOptions::LangOptions()' tutorial1.cpp:(.text+0x125): undefined reference to `clang::FileManager::FileManager(clang::FileSystemOptions const&)' tutorial1.cpp:(.text+0x148): undefined reference to `clang::SourceManager::SourceManager(clang::DiagnosticsEngine&, clang::FileManager&)' tutorial1.cpp:(.text+0x17c): undefined reference to `llvm::sys::getDefaultTargetTriple()' tutorial1.cpp:(.text+0x1d0): undefined reference to `clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&, clang::Ta...

...orial1.cpp:(.text+0xf4): undefined reference to > `clang::LangOptions::LangOptions()' > tutorial1.cpp:(.text+0x125): undefined reference to > `clang::FileManager::FileManager(clang::FileSystemOptions const&)' > tutorial1.cpp:(.text+0x148): undefined reference to > `clang::SourceManager::SourceManager(clang::DiagnosticsEngine&, > clang::FileManager&)' > tutorial1.cpp:(.text+0x17c): undefined reference to > `llvm::sys::getDefaultTargetTriple()' > tutorial1.cpp:(.text+0x1d0): undefined reference to > `clang::TargetInfo::CreateTargetInfo(clang::Diagnost...

...orial1.cpp:(.text+0xf4): undefined reference to > `clang::LangOptions::LangOptions()' > tutorial1.cpp:(.text+0x125): undefined reference to > `clang::FileManager::FileManager(clang::FileSystemOptions const&)' > tutorial1.cpp:(.text+0x148): undefined reference to > `clang::SourceManager::SourceManager(clang::DiagnosticsEngine&, > clang::FileManager&)' > tutorial1.cpp:(.text+0x17c): undefined reference to > `llvm::sys::getDefaultTargetTriple()' > tutorial1.cpp:(.text+0x1d0): undefined reference to > `clang::TargetInfo::CreateTargetInfo(clang::Diagnost...

...langSema.a ..\..\..\..\lib\libclangAST.a ..\..\..\..\lib\libclangLex.a ..\..\..\..\lib\libclangBasic.a -lgcc_eh -lgcc_eh -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 ..\..\..\..\lib\libclangFrontend.a(ASTUnit.cpp.obj):ASTUnit.cpp:(.text$_ZN5clang13SourceManagerC1Ev[clang::SourceManager::SourceManager()]+0xf): undefined reference to `llvm::BumpPtrAllocator::DefaultSlabAllocator' ..\..\..\..\lib\libclangFrontend.a(ASTUnit.cpp.obj):ASTUnit.cpp:(.text$_ZN5clang13SourceManagerC1Ev[clang::SourceManager::SourceManager()]+0x27): undefined reference to `llvm::...

...elease build llvm[4]: Compiling ConvertUTF.c for Release build llvm[4]: Compiling Diagnostic.cpp for Release build llvm[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 'llv...

...Consumer*, bool)' tutorial1.cpp:(.text+0xf4): undefined reference to `clang::LangOptions::LangOptions()' tutorial1.cpp:(.text+0x125): undefined reference to `clang::FileManager::FileManager(clang::FileSystemOptions const&)' tutorial1.cpp:(.text+0x148): undefined reference to `clang::SourceManager::SourceManager(clang::DiagnosticsEngine&, clang::FileManager&)' tutorial1.cpp:(.text+0x17c): undefined reference to `llvm::sys::getDefaultTargetTriple()' tutorial1.cpp:(.text+0x1d0): undefined reference to `clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&, clang::Ta...

...languageOptions; languageOptions.GNUMode = 1; languageOptions.CXXExceptions = 1; languageOptions.RTTI = 1; languageOptions.Bool = 1; languageOptions.CPlusPlus = 1; clang::FileSystemOptions fileSystemOptions; clang::FileManager fileManager(fileSystemOptions); clang::SourceManager sourceManager( *pDiagnosticsEngine, fileManager); clang::TargetOptions targetOptions; targetOptions.Triple = "x86_64-unknown-linux-gnu"; targetOptions.CPU = "x86-64"; clang::TargetInfo *pTargetInfo = clang::TargetInfo::CreateTargetInfo(...

...(and still blazing fast) > file system abstraction? Yes, please! Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. > Pro: > - only one interface for developers to learn on the project (no more > PathV1 vs PathV2 vs FileManager) > - only one implementation (per-platform) for easier maintenance of the > file sys...

...CompilerInvocation, CompilerInstance and `clang -cc1` in general) should remain in Clang. Later we can decide that there are some commonalities that can be shared, but these are expected to be relatively small. In terms of the infra code, libclangDriver requires DiagnosticEngine, which contains SourceManager and also requires SourceLocation. This would suggest the following steps. 1a. Generalize SourceManager so that it's suitable for both Clang and Flang 1b. Move the updated SourceManager, together with SLocEntry, SourceLocation, FileManager, VFS to `frontend-support` (i.e. the new location fo...

...mory of the front end (commonly clang but I think we want this to be front end agnostic). I'm now exploring ideas to avoid reopening files and let LLVM reuse the files the FE had to open. I am assuming that the front end will use llvm::MemoryBuffer (e.g.: clang does indirectly through clang::SourceManager). So for buffers related to named files (including stdin, which does not have name and is handled in a special way) we could have in the LLVM context a MemoryBufferRegistry. The idea is to add new creators of MemoryBuffer (the ones that work on named files and stdin) that can be passed a reference...

...eat :) /me jumps right into the design discussion then. > >> Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >> >>> Pro: >>> - only one interface for developers to learn on the project (no more >>> PathV1 vs PathV2 vs FileManager) >>> - only one implementation (per-platform) for...

...me jumps right into the design discussion then. >> >>> Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>> >>>> Pro: >>>> - only one interface for developers to learn on the project (no more >>>> PathV1 vs PathV2 vs FileManager) >>>> - only one implementatio...

...right into the design discussion then. >>> >>>> Having a proper virtual file system across Clang and LLVM would be a huge boon, especially for pushing Clang into more applications that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>>> >>>>> Pro: >>>>> - only one interface for developers to learn on the project (no more >>>>> PathV1 vs PathV2 vs FileManager) >>>>> - on...

Add -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS to your compilation flag. On 7/10/2012 11:23 AM, NY Knicks Fan wrote: > Hi Ashok, > > I created a new Ubuntu 12.04 virtual machine and followed directions > except that I know use your cmake command instead of configure, and I > got the error below. > > Any help is very much appreciated. > > > $