search for: declcontext

Been having a bit of a problem with dyn_cast: Suppose I have a class A that inherits from two base classes, both of which support dyn_cast. In order to use dyn_cast on A, I need to do a bunch of extra work: 1) Since dyn_cast uses reinterpret_cast rather than static_cast, the pointer value won't get adjusted by the cast operation, making the pointer invalid. I end up having to redefine

Hello, I recently ran into an issue where I wanted to use dyn_cast with a Multiple Inheritance hierarchy. LLVM’s help page on RTTI claims that it can be done, and that Clang’s Decl and DeclContext implement it; however, when I try to use it I run into odd behavior. Here’s my sample code which doesn’t work: ``` struct Base { void *ptr; bool hasInfo; }; struct Info { int size; static bool classof(const Base *b) { return b->hasInfo; }; }; struct Child : public Base { Child() {...

...his)) return I->getOpcode(); return cast<ConstantExpr>(this)->getOpcode(); } In this function, the `this` pointer is not pointing at an Operator object. That's undefined behavior, right? The problem that this Operator is trying to solve is similar to the situation with DeclContext's inside Clang. The primary difference is that while Operator isn't actualy a parent, DeclContext is a proper parent (using multiple inheritance), and so these casts become legit cross-casts for DeclContext. I'm not sure if multiple inheritance is the right solution here, but we definit...

On 3 May 2018, at 22:09, David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below

Hello, In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below too ugly/problematic? Feedback would be appreciated. Thanks, Dave //===- llvm/Support/VTable.h - LLVM-style

...: Compiling IndexingContext.cpp for Release+Asserts build (PIC) /home/ecsardu/LLVM/llvm/tools/clang/tools/libclang/IndexingContext.cpp: In member function 'void clang::cxindex::IndexingContext::handleReference(const clang::NamedDecl*, clang::SourceLocation, const clang::NamedDecl*, const clang::DeclContext*, const clang::Expr*, CXIdxEntityRefKind)': /home/ecsardu/LLVM/llvm/tools/clang/tools/libclang/IndexingContext.cpp:401:68: warning: cast from type 'const clang::Decl*' to type 'clang::Decl*' casts away qualifiers llvm[4]: Linking Release+Asserts Shared Library libclang.so This...

...Results ==== Given the above steps, I've done some quick analysis with my favourite spreadsheet application where I'm showing the top results for the Clang run above. Here's some interesting findings: - The top 20 functions called in clang (in the above invocation) are: 292174 clang::DeclContext::getPrimaryContext() 283681 llvm::FoldingSetNodeID::AddPointer(void const*) 214706 clang::Preprocessor::Lex(clang::Token&) 193352 llvm::FoldingSetNodeID::AddInteger(unsigned int) 161706 clang::Lexer::LexTokenInternal(clang::Token&, bool) 161055 clang::Lexer::Lex(clang::Token&) 143420 cl...

Hi all， Clang use a hash table to store all its identifiers. The hash table definition is: typedef llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator> HashTableTy; HashTableTy HashTable; Can anyone explain the mechnism of handling the name string key collision for me? Is there a IdentifierInfo objects chain or list for variable or function with the same name? Thanks very much!

Hi, I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. Cheers, James ________________________________________ From: Csaba Raduly [rcsaba at gmail.com] Sent: 23 October 2011 18:44 To: James Molloy Cc: Paul Berube; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] build warnings On Sat, Oct 22,

On Sat, Oct 22, 2011 at 12:24 AM, James Molloy wrote: > Hi Paul, > > That should be easy enough, because the LLVM build has no warnings in it! > > Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) So, all the "variable might be used

...class exists at the same level and isn't exactly the same. So quite a bit of clang work if we want to make this work. Each symbol file installs itself as an external AST source so if we wanted to add the template member functions on the fly, hopefully we would get a request that says in the DeclContext "class A" what is "Foo" if you type something like: A a; (lldb) a.Foo<int>() But I am not sure what clang will do if it already thinks it knows the definition for class A, so we might need to teach clang, that in debugger mode only, check the external AST source if there...

How do you handle name lookup for nested classes? They have the same problem (they don't appear in all definitions) - don't appear in all descriptions of the outer/parent class. (in theory we could ensure there's always at least a declaration of the nested class - but we don't even do that if the nested class is unused) Is it just the case that Clang doesn't mind you adding a

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)

...lyzed sequentially and cloned > > sequentially. Cloning is started in parallel with analyzing. That scheme > > could be changed: analyzing and cloning could be done in parallel for each > > object file. That requires refactoring of DWARFLinker and making string > > pools and DeclContextTree thread-safe. > > I'm less familiar with the way that LLD uses the DWARFOptimizer but this is > not possible for dsymutil as it is trying to deduplicate DIEs from different > compile units. > > Right. dsymutil is trying to de-duplicate DIEs from different > compile units...

...object files are analyzed sequentially and cloned > sequentially. Cloning is started in parallel with analyzing. That scheme > could be changed: analyzing and cloning could be done in parallel for each > object file. That requires refactoring of DWARFLinker and making string > pools and DeclContextTree thread-safe. I'm less familiar with the way that LLD uses the DWARFOptimizer but this is not possible for dsymutil as it is trying to deduplicate DIEs from different compile units. > I think improving dsymutil is a valuable thing. Though there are several > directions which might be...

Hi All, This is something that's been talked about for some time and it's probably time to propose it. The "We" in this document is everyone on the cc line plus me. Please go ahead and take a look. Thanks! -eric Objective (and TL;DR) ================= Migrate debug type information generation from the backends to the front end. This will enable: 1. Separation of

Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from