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

[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]
https://github.com/esbmc/esbmc/blob/master/src/clang-c-frontend/AST/esbmc_action.h
[1]
https://github.com/esbmc/esbmc/blob/master/src/clang-c-frontend/clang_c_language.cpp#L206
[2]
https://github.com/esbmc/esbmc/blob/master/src/clang-c-frontend/AST/esbmc_action.h#L31

-- 

Mikhail Ramalho.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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 preprocessor
[2].

[0]
https://github.com/esbmc/esbmc/blob/master/src/clang-c-frontend/AST/esbmc_action.h
[1]
https://github.com/esbmc/esbmc/blob/master/src/clang-c-frontend/clang_c_language.cpp#L206
[2]
https://github.com/esbmc/esbmc/blob/master/src/clang-c-frontend/AST/esbmc_action.h#L31


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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 offset, so the original code 
should work just fine in presence of line markers.
I don't see why changing to presumed locations fixes the issue with not 
generating the USRs.

Could you provide a minimal example where USRs are not generated? It might be 
the case that there are other ways to fix it.


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

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

[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:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html

For instance:

$ cat foo.c

int f(int a);

# 1 "file1.c" 1
int g(int b);

clang generates:

|-FunctionDecl 0x6866ff0  col:5 f 'int (int)'
| `-ParmVarDecl 0x6866f30  col:11 a 'int'
`-FunctionDecl 0x6867138  col:5 g 'int (int)'
  `-ParmVarDecl 0x68670b0  col:11 b 'int'

Note that the location of f and g are different, despite being in the same
file.

The preprocessor inserts linemarkers by default:

$ clang foo.c -E
# 1 "foo.c"
# 1 "" 1
# 1 "" 3
# 349 "" 3
# 1 "" 1
# 1 "" 2
# 1 "foo.c" 2

int f(int a);


# 1 "file1.c" 1
int g(int b);

unless you call it with -P:

$ clang foo.c -E -P

int f(int a);


int g(int b);



> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D42966
>
>
>
>


-- 

Mikhail Ramalho.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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 linemarker:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html

For instance:

$ cat foo.c

int f(int a);

1 "file1.c" 1
=

int g(int b);

clang generates:

| -FunctionDecl 0x6866ff0  col:5 f 'int (int)' |
| `-ParmVarDecl 0x6866f30  col:11 a 'int'  |
|

`-FunctionDecl 0x6867138  col:5 g 'int (int)'

  `-ParmVarDecl 0x68670b0  col:11 b 'int'

Note that the location of f and g are different, despite being in the same
file.

The preprocessor inserts linemarkers by default:

$ clang foo.c -E

1. 1 "foo.c"
2. 1 "" 1
3. 1 "" 3
4. 349 "" 3
5. 1 "" 1
6. 1 "" 2
7. 1 "foo.c" 2

int f(int a);

1 "file1.c" 1
=

int g(int b);

unless you call it with -P:

$ clang foo.c -E -P

int f(int a);

int g(int b);

> Repository:
> 
>   rC Clang
> 
> https://reviews.llvm.org/D42966


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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 calculate the offset of the decl in the virtual file?

Where do virtual files come from in the first place?


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

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

[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, what to do when there are
linemarkers that change the filename/line number?

Should we ignore linemarkers and use filename + offset of the real file?
Should we try to calculate the offset of the decl in the virtual file?

Thank you,

-- 

Mikhail Ramalho.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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 we're back to the initial question, what to do when there are
linemarkers that change the filename/line number?

Should we ignore linemarkers and use filename + offset of the real file?
Should we try to calculate the offset of the decl in the virtual file?

Thank you,


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

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

[Sam McCall via Phabricator via cfe-commits]

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 I think is the current behavior.
>
> What do you man by location information? Only the filename or filename +
>  offset (current behaviour)?


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.


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

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

[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 +
offset (current behaviour)?

-- 

Mikhail Ramalho.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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 information? Only the filename or filename +
offset (current behaviour)?


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

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

[Sam McCall via Phabricator via cfe-commits]

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 extension case I don't really understand

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.

(I think for the patch itself we're waiting on details about the case that 
doesn't currently work?)


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

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

[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 (USRGeneration.cpp:38) and the USR is not generated.

I believe the USR gen for params should have follow the functionDecl
convention. I'm reworking the patch now.


> int func(int param1);
> int func(int param2);
> // param1 and param2 could both have the same USR, but different names.
> That might (or might not) be surprising.
>

I agree here, they should have the same USR.


-- 

Mikhail Ramalho.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Ilya Biryukov via Phabricator via cfe-commits]

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 forces printLoc to
>  return true (USRGeneration.cpp:38) and the USR is not generated.


I still don't get why the file is virtual. Looking at the code in 
`SourceManager`, presumed location uses `FileEntry` of passed location 
(actually, its expansion location, but that shouldn't matter) and then 
translates line numbers according to the `#line` directives in the file.
So the question is: why is `FileEntry` null for original location, but not null 
for `PresumedLoc`?

Sorry for confusion, if any, I just want to understand to make sure we're 
looking at the right place to solve your original problem.

>> int func(int param1);
>>  int func(int param2);
>>  // param1 and param2 could both have the same USR, but different names.
>>  That might (or might not) be surprising.
> 
> I agree here, they should have the same USR.

Let's get more opinions on this, I'm not 100% certain about it myself :-)

@arphaman, @bkramer, @hokein, @ioeric, @sammccall, should parameters of 
**different declarations** for the **same function overload** have the same or 
different USRs? WDYT?


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

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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 it is NULL (USRGeneration.cpp:33), which forces printLoc to
return true (USRGeneration.cpp:38) and the USR is not generated.

I believe the USR gen for params should have follow the functionDecl
convention. I'm reworking the patch now.

> int func(int param1);
>  int func(int param2);
>  // param1 and param2 could both have the same USR, but different names.
>  That might (or might not) be surprising.

I agree here, they should have the same USR.


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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`?


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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 it to get the PresumedLoc.


That's the part I'm confused about.
Does any of the examples in the current patch have this case (files are not 
registered in the source manager, but defined by the file markers)?
I assume all examples in the current patch will produce USRs even without your 
changes, is this correct or am I missing something?

> More general question is: how do we want USRs for function parameters to
> 
>> work, specifically should USR of the same param of different declarations
>>  be the same or different?
> 
> That's a good point, this patch will generated different names for the same
>  function param if a function is first defined then declared somewhere else.
> 
> I guess it should follow the USR generation pattern for FunctionDecls, what
>  do you think?

I guess it depends on the use-case, but  USRs for function params do not seem 
to provide much value if they aren't equal across different decls of the same 
function.

But I'm not sure whether they were designed with this use-case in mind or not.
E.g. if they **are** equal, we can two `Decl`s with the same USR, but different 
names:

  int func(int param1);
  int func(int param2); 
  // param1 and param2 could both have the same USR, but different names. That 
might (or might not) be surprising.


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

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

[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 fail, that's why I changed it to get the PresumedLoc.

More general question is: how do we want USRs for function parameters to
> work, specifically should USR of the same param of different declarations
> be the same or different?
>

That's a good point, this patch will generated different names for the same
function param if a function is first defined then declared somewhere else.

I guess it should follow the USR generation pattern for FunctionDecls, what
do you think?

-- 

Mikhail Ramalho.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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 in the SourceManager as actual files, so getting the
FileEntry will always fail, that's why I changed it to get the PresumedLoc.

More general question is: how do we want USRs for function parameters to

> work, specifically should USR of the same param of different declarations
>  be the same or different?

That's a good point, this patch will generated different names for the same
function param if a function is first defined then declared somewhere else.

I guess it should follow the USR generation pattern for FunctionDecls, what
do you think?


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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 is 
> no actual file


Why wasn't there a file for function parameter? Function parameters *are* 
declared in some file, or am I missing something?

More general question is: how do we want USRs for function parameters to work, 
specifically should USR of the same param of different declarations be the same 
or different?


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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, that's why I changed to get the presumedLoc and build the name 
> using the column/line.
>
> I know that using column/line not the preferable method to generate USR but I 
> couldn't find a way to generate the offset of a presumed location.





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

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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

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

[Mikhail Ramalho via Phabricator via 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 column/line.

I know that using column/line not the preferable method to generate USR but I 
couldn't find a way to generate the offset of a presumed location.


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

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

[Ilya Biryukov via Phabricator via cfe-commits]

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
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mikhail Ramalho via Phabricator via cfe-commits]

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

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

[Mikhail Ramalho via Phabricator via 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 Func(int arg);
  
  #line 10 "file.h"
  int Func(int arg1);
  
  # 1 "file1.c" 1
  int Func(int arg);

These testes were added to test/Index/usrs.cpp.

I changed the printLoc function to, instead of adding the declaration offset to 
the name, it gets the presumedLoc (which handles line directives or 
linemarkes), and adds the line and column to the name, in the format 
:.

The patch only changes the printLoc function in lib/index/USRGeneration.cpp; 
the other changes are test updates.


Repository:
  rC Clang

https://reviews.llvm.org/D42966

Files:
  lib/Index/USRGeneration.cpp
  test/Index/cxx11-lambdas.cpp
  test/Index/get-cursor.cpp
  test/Index/index-templates.cpp
  test/Index/pch-opaque-value.cpp
  test/Index/usrs.cpp
  test/Index/usrs.m

Index: test/Index/usrs.m
===
--- test/Index/usrs.m
+++ test/Index/usrs.m
@@ -102,14 +102,14 @@
 
 // RUN: c-index-test -test-load-source-usrs all -target x86_64-apple-macosx10.7 %s -isystem %S/Inputs | FileCheck %s
 // CHECK: usrs-system.h c:@macro@MACRO_FROM_SYSTEM_HEADER_1 Extent=[1:9 - 1:40]
-// CHECK: usrs.m c:usrs.m@1265@macro@MACRO1 Extent=[94:9 - 94:19]
-// CHECK: usrs.m c:usrs.m@1285@macro@MACRO2 Extent=[96:9 - 96:19]
-// CHECK: usrs.m c:usrs.m@1318@macro@MACRO2 Extent=[98:9 - 98:19]
-// CHECK: usrs.m c:usrs.m@1338@macro@MACRO3 Extent=[100:9 - 100:25]
-// CHECK: usrs.m c:usrs.m@1363@macro@MACRO3 Extent=[101:9 - 101:25]
+// CHECK: usrs.m c:usrs.m@94:9@macro@MACRO1 Extent=[94:9 - 94:19]
+// CHECK: usrs.m c:usrs.m@96:9@macro@MACRO2 Extent=[96:9 - 96:19]
+// CHECK: usrs.m c:usrs.m@98:9@macro@MACRO2 Extent=[98:9 - 98:19]
+// CHECK: usrs.m c:usrs.m@100:9@macro@MACRO3 Extent=[100:9 - 100:25]
+// CHECK: usrs.m c:usrs.m@101:9@macro@MACRO3 Extent=[101:9 - 101:25]
 // CHECK: usrs.m c:usrs.m@F@my_helper Extent=[3:1 - 3:60]
-// CHECK: usrs.m c:usrs.m@95@F@my_helper@x Extent=[3:29 - 3:34]
-// CHECK: usrs.m c:usrs.m@102@F@my_helper@y Extent=[3:36 - 3:41]
+// CHECK: usrs.m c:usrs.m@3:29@F@my_helper@x Extent=[3:29 - 3:34]
+// CHECK: usrs.m c:usrs.m@3:36@F@my_helper@y Extent=[3:36 - 3:41]
 // CHECK: usrs.m c:@Ea@ABA Extent=[5:1 - 8:2]
 // CHECK: usrs.m c:@Ea@ABA@ABA Extent=[6:3 - 6:6]
 // CHECK: usrs.m c:@Ea@ABA@CADABA Extent=[7:3 - 7:9]
@@ -131,22 +131,22 @@
 // CHECK: usrs.m c:objc(cs)Foo(py)d1 Extent=[31:1 - 31:17]
 // CHECK: usrs.m c:objc(cs)Foo(im)d1 Extent=[31:15 - 31:17]
 // CHECK: usrs.m c:objc(cs)Foo(im)setD1: Extent=[31:15 - 31:17]
-// CHECK: usrs.m c:usrs.m@352objc(cs)Foo(im)setD1:@d1 Extent=[31:15 - 31:17]
+// CHECK: usrs.m c:usrs.m@31:15objc(cs)Foo(im)setD1:@d1 Extent=[31:15 - 31:17]
 // CHECK: usrs.m c:objc(cs)Foo Extent=[34:1 - 45:2]
 // CHECK: usrs.m c:objc(cs)Foo(im)godzilla Extent=[35:1 - 39:2]
-// CHECK: usrs.m c:usrs.m@402objc(cs)Foo(im)godzilla@a Extent=[36:3 - 36:19]
+// CHECK: usrs.m c:usrs.m@36:3objc(cs)Foo(im)godzilla@a Extent=[36:3 - 36:19]
 // CHECK: usrs.m c:@z Extent=[37:3 - 37:15]
 // CHECK: usrs.m c:objc(cs)Foo(cm)kingkong Extent=[40:1 - 43:2]
-// CHECK: usrs.m c:usrs.m@470objc(cs)Foo(cm)kingkong@local_var Extent=[41:3 - 41:16]
+// CHECK: usrs.m c:usrs.m@41:3objc(cs)Foo(cm)kingkong@local_var Extent=[41:3 - 41:16]
 // CHECK: usrs.m c:objc(cs)Foo(py)d1 Extent=[44:1 - 44:15]
 // CHECK: usrs.m c:@z Extent=[47:1 - 47:6]
 // CHECK: usrs.m c:usrs.m@F@local_func Extent=[49:1 - 49:43]
-// CHECK: usrs.m c:usrs.m@551@F@local_func@x Extent=[49:23 - 49:28]
+// CHECK: usrs.m c:usrs.m@49:23@F@local_func@x Extent=[49:23 - 49:28]
 // CHECK: usrs.m c:objc(cs)CWithExt Extent=[51:1 - 53:5]
 // CHECK: usrs.m c:objc(cs)CWithExt(im)meth1 Extent=[52:1 - 52:14]
-// CHECK: usrs.m c:objc(ext)CWithExt@usrs.m@612 Extent=[54:1 - 56:5]
+// CHECK: usrs.m c:objc(ext)CWithExt@usrs.m@54:1 Extent=[54:1 - 56:5]
 // CHECK: usrs.m c:objc(cs)CWithExt(im)meth2 Extent=[55:1 - 55:14]
-// CHECK: usrs.m c:objc(ext)CWithExt@usrs.m@654 Extent=[57:1 - 59:5]
+// CHECK: usrs.m c:objc(ext)CWithExt@usrs.m@57:1 Extent=[57:1 - 59:5]
 // CHECK: usrs.m c:objc(cs)CWithExt(im)meth3 Extent=[58:1 - 58:14]
 // CHECK: usrs.m c:objc(cy)CWithExt@Bar Extent=[60:1 - 62:5]
 // CHECK: usrs.m c:objc(cs)CWithExt(im)meth4 Extent=[61:1 - 61:14]
@@ -158,13 +158,13 @@
 // CHECK: usrs.m c:objc(cs)CWithExt(im)meth4 Extent=[69:1 - 69:27]
 // CHECK: usrs.m c:@F@aux_1 Extent=[72:1 - 72:26]
 // CHECK: usrs.m c:@F@test_multi_declaration Extent=[73:1 - 77:2]
-// CHECK: usrs.m c:usrs.m@980@F@test_multi_declaration@foo Extent=[74:3 - 74:14]
-// CHECK: usrs.m c:usrs.m@980@F@test_multi_declaration@bar Extent=[74:16 - 74:23]
-// CHECK: usrs.m c:usrs.m@980@F@test_multi_declaration@baz Extent=[74:25 - 74:32]
+// CHECK: usrs.m c:usrs.m@74:3@F@test_multi_declaration@foo