429446 - dehydra could handle constant nodes better

Status: RESOLVED FIXED

(Developer Infrastructure :: Source Code Analysis, enhancement)

Description

[Vlad Sukhoy]

Currently dehydra uses gcc's pretty-printer to produce JS objects for tree nodes corresponding to constants. It turned out that gcc's pretty printer behavior is quite weird (if not buggy) in certain circumstances: see bug 429362.

Besides pretty printer issues it may be beneficial for certain JS analyses which may have to deal with constants to be able to access the information about the type of the constant in a way that is consistent with the rest of dehydra (i.e. via .type property on the JS object corresponding to the constant). Currently, such analyses would have to extract this type information from the output of the pretty printer (e.g. the value of the constant "123ull" implies that this is the unsigned long long constant with numeric value 123).

If dehydra could provide .type property for constants then there would be no need for pretty printer's representation, moreover, the appropriate JS type could be used for .value property of a constant object where feasible (i.e. for a zero constant the .value would be 0 versus "0" or "0u" or other variants which may be produced by pretty printer).

Comment 1

[Vlad Sukhoy]

After brief discussion we decided that .type is a good idea, but messing with .value is not.

Comment 2

[Vlad Sukhoy]

Attachment: wip

work in progress on .type prop on constants, seems not to work on linux when dehydra bootstraps treehydra.

Comment 3

[Vlad Sukhoy]

Attachment: setup .type on constant objects

Fixed remaining issues: constants of some unique types may be seen during bootstrap of treehydra.

Comment 4

[(dormant account)]

Comment on attachment 319794 [details] [diff] [review]
setup .type on constant objects

Looks good, but please get rid of nested ternaries

Comment 5

[Vlad Sukhoy]

did so and pushed.