Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Suggestions for dealing with tests

I had a closer look at the standard and I agree with you:

pp-number contains any number including user defined literals. But for preprocessing the characters and strings are distinct from user defined characters and strings, considering preprocessing tokens (from translation phase 3).

Looking at translation phase 7 (conversion of preprocessing tokens to tokens) user defined literals are distinct from the other kinds of literals [lex.literal.kinds], with the subcategories int, float, char and string.

From the description the conversion of the tokens seems to me like a pre-step of phase 7. But I guess it could be done on the fly, while parsing as well.

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
Sent: Montag, 11. Juni 2012 11:31
To: CDT General developers list.
Subject: Re: [cdt-dev] Suggestions for dealing with tests

 

Hi,

A user-defined literal is still of kind integer, char, floating-point or string. So it’d be natural to add the property isUserDefined() to IASTLiteralExpression.

 

Yes, dealing with the suffix is the parsers task. By the standard it’s even the task of the parser to distinguish between the various kinds of number literals. I don’t exactly know why this is done in the preprocessor. It’d be actually nice to move this task away from it, which would collapse the various kinds of number tokens to one preprocessor number token as described in 2.10.

However, the LR-Parsers probably rely on receiving the tokens as they are delivered today. So we could have an option whether the preprocessor shall classify the number tokens or not. For the GNUCPPSourceParser we could then move the classification into the parser.

 

Exactly, CPPASTLiteralExpresion.getExpressionType() needs to be changed. Plus, as mentioned before, by using IASTImplicitNameOwner the literal _expression_ can provide the binding to the operator that is called to create the object denoted by the literal.

 

Markus.

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Corbat Thomas (tcorbat@xxxxxx)
Sent: Monday, June 11, 2012 9:42 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Suggestions for dealing with tests

 

Hi

 

Regarding the UDL implementation:

So your suggestion, Markus, is to lex user defined literals as tSTRING, tCHAR, tINTEGER and tFLOATINGPT?

Shall IASTExpression get a new kind for user defined literals?

Recognizing the suffix will be task of the parser then, right?

I guess getExpressionType() in CPPASTLiteralExpression must be extended to return the type of the resolved literal operator.

 

That probably makes the implementation a bit easier.

 

Regards

Thomas

 

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
Sent: Montag, 11. Juni 2012 07:51
To: CDT General developers list.
Subject: Re: [cdt-dev] Suggestions for dealing with tests

 

Hi,

The preprocessor is not run in a specific language. In case there needs to be different behavior for C and C++ you need to introduce an option which should be controlled via IScannerExtensionConfiguration (The GPPLanguage and the GCCLanguage provide different objects for this configuration). The testcase needs to be elaborated to test with the two different configurations.

For the case, where we allow user defined literals the checkNumber method needs to behave differently. I also think that the classification of the number literals in the lexer needs to be changed, however it can be done, such that it works independently of whether user-defined literals are allowed or not.

My recommendation is to neither introduce new kinds of tokens nor to create a new IASTNode. I think it is sufficient to let CPPASTLiteralExpression implement IASTImplicitNameOwner, which allows to provide the references to the implicit function calls.  

The tests nested in org.eclipse.cdt.core.suite.AutomatedIntegrationSuite should all pass.

Markus.

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard
Sent: Saturday, June 09, 2012 10:35 PM
To: CDT General developers list.
Subject: [cdt-dev] Suggestions for dealing with tests

 

Hello all,

I've been working on getting user-defined literals working syntactically for the past week, I believe I'm in the home stretch as I'm now working through the failing test cases under org.eclipse.cdt.core.tests. 

I have a few questions regarding this. 

 

- Firstly, how do I deal with tests that are supposed to fail in C mode, but pass in C++ mode?

The current test that demonstrates this is PerprocessorTests.testGCC43BinaryNumbers. 

There are 5 binary literals that are tested for failing: 0b012, 0b01b, 0b1111e01, 0b1111p10, 0b10010.10010

With UDLs the first and the last of these should fail, and the middle three can be considered binary literals with UDL suffixes. But in C mode, or C++ sans UDL, they all should fail. Is there a way to test which language the current test is being run in?

 

- Lastly, I've been testing my branch against master, and I've noticed there are a fair number of tests with errors or failing. Is this expected, or do I have my project set up incorrectly?

 

Thank, Richard


Back to the top