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 5c6d3f0b427..b213
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 Mikha
>
>
> 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 your
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 i
>
>
> 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]
https://githu
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:
https://gcc.gnu.o
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, w
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
> feedback
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
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 (US
>
> 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 fa
11 matches
Mail list logo
