>
>
> 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]
mikhail.ramalho added a comment.
> 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
ilya-biryukov added a comment.
In https://reviews.llvm.org/D42966#1085303, @mikhail.ramalho wrote:
> Hi,
>
> > Where do virtual files come from in the first place?
>
> From the linemarker:
I tried dumping locations in presence of line markers.
They have non-null `FileEntry` and a reasonable
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:
mikhail.ramalho added a comment.
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
ilya-biryukov added a comment.
In https://reviews.llvm.org/D42966#1085257, @mikhail.ramalho wrote:
> Should we ignore linemarkers and use filename + offset of the real file?
I would say "yes". Let's not rely on linemarkers, unless we can explain why
that's a good idea.
> Should we try to
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,
mikhail.ramalho added a comment.
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
sammccall added a comment.
In https://reviews.llvm.org/D42966#1083954, @mikhail.ramalho wrote:
> 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
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
mikhail.ramalho added a comment.
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
sammccall added a comment.
Re: locations in parameter USRs:
OK, so reading through the code, it looks like locations are included in USRs:
- for macros (except from system headers)
- for decls that aren't externally visible (static etc, function parameters,
locals)
- an objective-c class
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
ilya-biryukov added subscribers: sammccall, ioeric, hokein, bkramer.
ilya-biryukov added a comment.
In https://reviews.llvm.org/D42966#1079438, @mikhail.ramalho wrote:
> The virtual file is actually registered in the SourceManager but the
> FileEntry for it is NULL (USRGeneration.cpp:33), which
mikhail.ramalho added a subscriber: rsmith.
mikhail.ramalho added a comment.
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
ilya-biryukov added a comment.
> I assume all examples in the current patch will produce USRs even without
> your changes, is this correct or am I missing something?
Or is the that whenever there's a `#line` directive we get into a "virtual"
file that's not registered in the `SourceManager`?
ilya-biryukov added a comment.
In https://reviews.llvm.org/D42966#1077249, @mikhail.ramalho wrote:
> 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 fail, that's why I changed
>
> 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
mikhail.ramalho added a subscriber: arphaman.
mikhail.ramalho added a comment.
> 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
ilya-biryukov added a comment.
Sorry for the delay.
In https://reviews.llvm.org/D42966#1069674, @mikhail.ramalho wrote:
> Sure. Basically, the previous code would not generate the USR for the
> function's parameters.
> The issue was that SM.getFileEntryForID would return NULL because there
ilya-biryukov added a comment.
In https://reviews.llvm.org/D42966#1069674, @mikhail.ramalho wrote:
> Sure. Basically, the previous code would not generate the USR for the
> function's parameters.
>
> The issue was that SM.getFileEntryForID would return NULL because there is no
> actual file,
mikhail.ramalho added a comment.
ping.
Repository:
rC Clang
https://reviews.llvm.org/D42966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikhail.ramalho added a comment.
Sure. Basically, the previous code would not generate the USR for the
function's parameters.
The issue was that SM.getFileEntryForID would return NULL because there is no
actual file, that's why I changed to get the presumedLoc and build the name
using the
ilya-biryukov added a comment.
Could you elaborate on why the old behaviour is broken?
Repository:
rC Clang
https://reviews.llvm.org/D42966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
mikhail.ramalho added a comment.
ping.
Repository:
rC Clang
https://reviews.llvm.org/D42966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mikhail.ramalho created this revision.
mikhail.ramalho added reviewers: arphaman, rsmith.
Herald added a subscriber: cfe-commits.
Small change on how the USRGen code prints the location.
The patch fixes an issue when there are #line directives or linemarkes in the
file, e.g.:
#line 3
int
26 matches
Mail list logo
