dehydra: want process_decl callback

RESOLVED FIXED

Status

Firefox Build System
Source Code Analysis
RESOLVED FIXED
10 years ago
4 months ago

People

(Reporter: Benjamin Smedberg, Assigned: (dormant account))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
I want a callback for declarations:

process_decl(decl)

this should be fired for function and variable declarations that occur outside of class scope (process_type already hooks function/var declarations that occur within a class)
(Reporter)

Updated

10 years ago
Blocks: 437502
(Assignee)

Comment 1

10 years ago
To clarify:
Want template decls, typedef decls, variable decls, and function (forward+implementation?) decls.
Blocks: 449064
(Reporter)

Comment 2

10 years ago
templated function, templated class/struct, typedef, variables, and function decls. I don't need variable or function implementations, because those are already handled by process_var/process_function

Ideally that would include decls of specialized or partially-specialized classes, e.g.

template<class T, class U>
Foo
{ ... }; // process_decl for Foo<T, U>

template<class U>
Foo<T, nsISupports>
{ ... }; // process_decl for Foo<T, nsISupports>
(Assignee)

Comment 3

10 years ago
Created attachment 332995 [details] [diff] [review]
expose more stuff via process_var()

The idea here is to expose stuff dehydra already sees(no mods to gcc) to process_var and rename it to process_decl. I think it would be terrible to have a process_var/process_decl split, so I'd rather rename the function.

See the testcase for what's supported:
a) function forward decls are now seen, unless decl smashing occurs
b) typedef declarations
c) template declarations. Partial specializations are listed similar to template arguments. I'm not sure how to support full specializations as I haven't found what gcc does with them yet.

Once you review this, I'll also post a rename patch for process_var
Attachment #332995 - Flags: review?(benjamin)
(Reporter)

Comment 4

10 years ago
Comment on attachment 332995 [details] [diff] [review]
expose more stuff via process_var()

There's an odd commented-out "else" in the testcase.

I'm happy with this patch as a first pass, but comments to follow:
Attachment #332995 - Flags: review?(benjamin) → review+
(Reporter)

Comment 5

10 years ago
Template specializations don't do exactly what I want yet, but I'm happy to file a followup for them:

template<class T, int I>
class Foo
{
  T *mT;
};

template<class T>
class Foo<T, 1>
{
  T mT;
};

With your current patch, I get a single call to process_var with Foo and a .specializations array. This specializations array lists the template parameters for the specializations, but not the actual class declaration. Because the class declaration can be entirely different, I'd either like:

* the .specializations array to have the specialized type object
* or a separate call to process_decl with the specialized type.
(Assignee)

Comment 6

10 years ago
I'll dig some more. I might've missed where gcc hides this info.
(Assignee)

Comment 7

10 years ago
Created attachment 333326 [details] [diff] [review]
this gives you template decls..apply on top of previous

So I guess I can't pull out full specializations and full partial info out of template_decl, at least it isn't obvious. On the other hand, I was able to get the data from elsewhere. 
This should work for you.

Anything else you need?
(Reporter)

Comment 8

10 years ago
applied and basic testing seems to work fine. There's a pre-existing issue with complete speicializations of templates, caused by bug 418170, that I'll file separately.
(Assignee)

Comment 9

10 years ago
pushed
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

4 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.