Re: [PATCH] D54978: Move the SMT API to LLVM

2019-02-12 Thread Mikhail Ramalho via cfe-commits
Hi, Thank you for the discussion, I was finally able to reproduce the error. > Hello @ddcc. > I agree with your reasoning here and developed a patch based on this line > of thought: > > diff --git a/llvm/cmake/modules/FindZ3.cmake > b/llvm/cmake/modules/FindZ3.cmake > index

Re: r353370 - Generalised the SMT state constraints

2019-02-11 Thread Mikhail Ramalho via cfe-commits
Hi Douglas, thank you for the report. We are discussing the issue in https://reviews.llvm.org/D54975. @michaelplatings said he found a solution and I asked him to run the tests locally. If it indeed fixes the issue, I'd say we push it. Em seg, 11 de fev de 2019 às 20:13, escreveu: > Hi

Re: [PATCH] D45517: [analyzer] False positive refutation with Z3

2018-06-04 Thread Mikhail Ramalho via cfe-commits
> > > Awesome! Does it mean that the optimization for adding less constraints > was in fact buggy? > > I pretty sure it was not related to the optimizations, I removed them days ago (in the previous version of this patch) and the bug was still there. > > 2. Could it be something unrelated to

Re: [PATCH] D45517: [analyzer] False positive refutation with Z3

2018-06-01 Thread Mikhail Ramalho via cfe-commits
Hi, > Just a bit of context and to have some expectation management regarding > this patch. The main purpose of this implementation was to back a thesis. > It was made under a very serious time pressure and the main goal was to be > able to measure on real world projects as soon as possible and

Re: [PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

2018-05-15 Thread Mikhail Ramalho via cfe-commits
> > > Could you provide a minimal example where USRs are not generated? It might > be the case that there are other ways to fix it. > > Sure, I'll try to reduce our testcase, but basically we have an ASTFrontendAction [0] that adds a set of intrinsics [1] to the preprocessor [2]. [0]

Re: [PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

2018-05-02 Thread Mikhail Ramalho via cfe-commits
Hi, > I would say "yes". Let's not rely on linemarkers, unless we can explain > why that's a good idea. > > Sounds reasonable to me, specially considering cases like rename and find-declaration. > > Where do virtual files come from in the first place? > > >From the linemarker:

Re: [PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

2018-05-02 Thread Mikhail Ramalho via cfe-commits
Hi, > Filename + offset for things like function parameters, where we have to > identify the particular function declaration they're part of. > For static functions themselveds, just the filename. I think this is > current behavior in both cases. > > But then we're back to the initial question,

Re: [PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

2018-05-02 Thread Mikhail Ramalho via cfe-commits
Last review asked to change the test case, I just want to make sure everything is fine this time. 2018-05-02 8:54 GMT+01:00 Manuel Klimek via Phabricator < revi...@reviews.llvm.org>: > klimek added a comment. > > I believe this was accepted by rnk - are you waiting for specific further >

Re: [PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

2018-05-01 Thread Mikhail Ramalho via cfe-commits
Hi, > After thinking about this a bit, and use cases like rename and > find-declaration that could be USR based, I think including some location > information is the right way to go, which I think is the current behavior. > > What do you man by location information? Only the filename or filename

Re: [PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

2018-04-26 Thread Mikhail Ramalho via cfe-commits
Hi, > Or is the that whenever there's a `#line` directive we get into a > "virtual" file that's not registered in the `SourceManager`? > > The virtual file is actually registered in the SourceManager but the FileEntry for it is NULL (USRGeneration.cpp:33), which forces printLoc to return true

Re: [PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

2018-04-24 Thread Mikhail Ramalho via cfe-commits
> > Why wasn't there a file for function parameter? Function parameters *are* > declared in some file, or am I missing something? > > They are declared in some file defined by the line markers; the file are not registered in the SourceManager as actual files, so getting the FileEntry will always