Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] pdom extensions?


On Wed, Dec 8, 2010 at 11:33 AM, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx> wrote:
> reliance on code properties derived from implementation is problematic
Better then nothing if we talking about false positives.

So to summarize - it is better to implement generic properties solution which also solves problems with support
for gcc and other attributes.    

Honestly I don't see a need for implementation-derived properties if we can support attributes attached to declarations. 

 I am still not clear is PDOM can actually support flexible size records...

PDOM doesn't support variable-size records but it supports links between records. Take a look at PDOMNodeLinkedList as an example.

-sergey



On Wed, Dec 8, 2010 at 2:21 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:


On Wed, Dec 8, 2010 at 11:06 AM, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx> wrote:
It would be similar to these but calculated by semantic analyzer not defined by user.

It makes sense to support attributes too and keep them separate from the stuff calculated by the semantic analyzer. In general, reliance on code properties derived from implementation is problematic since implementation is not API and is subject to change.

Is there already support for such generic attributes?

 
Or this is hardcoded list? It has to be more that these attributes.

I don't think it's hardcoded but I don't know much about attributes.

-sergey 


On Wed, Dec 8, 2010 at 1:53 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:
Alena,
Do you have a compelling case for arbitrary "properties" or you just need to model C++0x (http://www2.research.att.com/~bs/C++0xFAQ.html#attributes) or gcc-style (http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html) attributes?

-sergey


On Wed, Dec 8, 2010 at 10:35 AM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx> wrote:

It’s built for speed, so, yeah it’s pretty low level. Adding fields to the classes will require a change in the version number and force reindexing. You could add a generic field for “properties” to all or some subset of PDOM node classes. So it’s like (a) but done generically as in (b).

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
Sent: Wednesday, December 08, 2010 11:26 AM


To: CDT General developers list.
Subject: Re: [cdt-dev] pdom extensions?

 

I looked at db implementation - it is very low level - records offset at stuff. I cannot see how we attach arbitrary data to it... Looks like it is hard coded to be fixes size. Am I missing something?

On Wed, Dec 8, 2010 at 10:34 AM, Mike Kucera <mkucera@xxxxxxxxxx> wrote:

I like option b. The ability to attach arbitrary key/value pairs to PDOM nodes might have a variety of uses.



Inactive hide details for Alena Laskavaia ---12/07/2010 08:48:47 PM---I think I need to create a framework not only for checkerAlena Laskavaia ---12/07/2010 08:48:47 PM---I think I need to create a framework not only for checker for also for


From:


Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>


To:


"CDT General developers list." <cdt-dev@xxxxxxxxxxx>


Date:


12/07/2010 08:48 PM


Subject:


[cdt-dev] pdom extensions?



I think I need to create a framework not only for checker for also for
extended semantic information that can
be used by other checker. For example I can keep the information that
function may return null (or never returns null).
This info need to be kept per function (per global variable, type, class, etc).

The question is where do I keep this information.
a) extend PDOM with specific semantic attributes?
b) use some sort of generic extensions that can be attached to PDOM nodes?
c) create totally different db?

Ideas?

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev




Back to the top