Community
Participate
Working Groups
Build ID: I20090313-0100 Looking at section 6.2.5 of the rationale for the C99 standard a 'signed int' is a designation for 'int'. Looking at 6.7.2 of the standard it shows int, signed and signed int as being equivalent. I think that this means that the IType for the variable in the following declarations should be the same: int a; signed int b; signed c; I've modified CBasicType to model this and updated AST2Tests.testBasicTypes to test this. More information: Currently testBasicType only checks the IType - should it also be checking the IASTSimpleDeclSpecifier?
Created attachment 130107 [details] Patch to CBasicType and tests.
Hmm, with the patch we loose the information whether a type has explicitly been specified as signed. This would affect the display of proposals in content assist. However the method isSameType() should be fixed. See CPPBasicType.
(In reply to comment #2) > Hmm, with the patch we loose the information whether a type has explicitly been > specified as signed. This would affect the display of proposals in content > assist. > However the method isSameType() should be fixed. See CPPBasicType. > I agree information has been lost from the IType, but it should still be there on the IASTSimpleDeclSpecifier. Should IType objects include syntax related information? I'd thought that IType objects were for semantic information. And given an "int" and a "signed int" are the same thing does it matter if the content assist doesn't distinguish between the two? If the signed information should definitely be retained I'll create a new patch with suitable tests.
(In reply to comment #3) > I agree information has been lost from the IType, but it should still be there > on the IASTSimpleDeclSpecifier. Types are also stored in the index, when working with those you would not have access to the ast. > Should IType objects include syntax related information? I'd thought that IType > objects were for semantic information. And given an "int" and a "signed int" > are the same thing does it matter if the content assist doesn't distinguish > between the two? I don't have a particular reason why the information should be part of IBasicType other than that it has been this way for years. I am just guessing that the information will influence the display of types (ugly 'unsigned int' instead of 'int' in potentially many places, for example potentially in the proposals of content assist).
Created attachment 130594 [details] New patch Leaving things the way they've always been seems like a good enough reason to me and I'd not really thought about the potential changes in the UI. In the new patch I've modified CBasicType.isSameType() so it treats signed int and int as equivalent and added a test.
Thanks, I have committed your patch. Fixed in 6.0 > 20090415.
