Hi all,

In Descent I'm using the mangleof, or signature, of a class or function to search it in the project, for "go to definition" and other functionalities.

The problem I'm facing is that the mangled representation is sometimes ambiguous for symbols defined in functions. For example:

---
module main;

class X {
}

X foo(X x) {
	class Bla {
		static class Foo {
			
		}
	}
	return null;
}
---

The mangleof of Foo is: C4main3fooFC4main1XZC4main1X3Bla3Foo

Decomposing the signature, we can deduce that:
- the function is 4main3foo = main.foo
- the first and only parameter is C4main1X = main.X
- the return type is C4main1X3Bla3Foo

The problem with the last point is I can't tell the return type is main.X, and then, nested in the function, there's Bla.Foo. It could perfectly be that the return type is main.X.Bla, and nested in the function there's Foo. In fact, this code compiles:

---
module main;

class X {
	static class Foo {
	
	}
	static class Bla {
		static class Foo {
			
		}
	}
}

static assert(X.Bla.Foo.mangleof == "C4main1X3Bla3Foo");

X foo(X x) {
	class Bla {
		static class Foo {
			static assert(Foo.mangleof ==
			"C4main3fooFC4main1XZC4main1X3Bla3Foo"); // 1
		}
	}
	return null;
}

X.Bla foo(X x) {
	class Foo {
		static assert(Foo.mangleof ==
			"C4main3fooFC4main1XZC4main1X3Bla3Foo"); // 2
	}
	return null;
}

// 1 and 2 are the same
---

My questions are: is there any reason for the signature to be ambigous? If so, how can I tell how to search a symbol from that signature? Or maybe I should create my own signatures just for searching symbols...

Thanks,
Ary

Ary Borenszweig wrote:
> Hi all,
> 
> In Descent I'm using the mangleof, or signature, of a class or function to search it in the project, for "go to definition" and other functionalities.
> 
> The problem I'm facing is that the mangled representation is sometimes ambiguous for symbols defined in functions. For example:

I mentioned a similar (or perhaps the same?) issue in http://d.puremagic.com/issues/show_bug.cgi?id=588#c2. (The issue is marked as 'resolved' because this wasn't what it was directly about, it was about a patch to std.demangle; it just happened to run into an ambiguity concerning nested symbols)

> My questions are: is there any reason for the signature to be ambigous? 

It was probably just an oversight when nested symbols (and thus their mangling) was added to the compiler.

> If so, how can I tell how to search a symbol from that signature? Or maybe I should create my own signatures just for searching symbols...

In my bugzilla comment I mentioned that adding a simple terminator character after identifiers would probably be the easiest fix. Since you have a fork of the frontend in descent, you could probably implement that pretty easily.

Frits van Bommel wrote:
> Ary Borenszweig wrote:
>> Hi all,
>>
>> In Descent I'm using the mangleof, or signature, of a class or function to search it in the project, for "go to definition" and other functionalities.
>>
>> The problem I'm facing is that the mangled representation is sometimes ambiguous for symbols defined in functions. For example:
> 
> I mentioned a similar (or perhaps the same?) issue in http://d.puremagic.com/issues/show_bug.cgi?id=588#c2. (The issue is marked as 'resolved' because this wasn't what it was directly about, it was about a patch to std.demangle; it just happened to run into an ambiguity concerning nested symbols)
> 
>> My questions are: is there any reason for the signature to be ambigous? 
> 
> It was probably just an oversight when nested symbols (and thus their mangling) was added to the compiler.
> 
>> If so, how can I tell how to search a symbol from that signature? Or maybe I should create my own signatures just for searching symbols...
> 
> In my bugzilla comment I mentioned that adding a simple terminator character after identifiers would probably be the easiest fix. Since you have a fork of the frontend in descent, you could probably implement that pretty easily.

Then I will implement a custom mangling for Descent. I wanted to know if I could reuse the manglging provided by DMD, since anyways I have to do the semantic pass, which creates the (sometimes ambiguous) signatures.

Thanks for the answer.