2009-07-14 00:45:15 +04:00
|
|
|
/*
|
|
|
|
|
* Copyright 2009, Ingo Weinhold, ingo_weinhold@gmx.de.
|
2014-10-26 00:19:38 +04:00
|
|
|
* Copyright 2014, Rene Gollent, rene@gollent.com.
|
2009-07-14 00:45:15 +04:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef SOURCE_LANGUAGE_H
|
|
|
|
|
#define SOURCE_LANGUAGE_H
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#include <Referenceable.h>
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 15:22:06 +04:00
|
|
|
class BString;
|
Debugger: Rework expression parsing API.
ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.
CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.
ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.
Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.
2014-11-15 08:31:17 +03:00
|
|
|
class ExpressionResult;
|
2009-07-14 00:45:15 +04:00
|
|
|
class SyntaxHighlighter;
|
2012-11-06 15:22:06 +04:00
|
|
|
class TeamTypeInformation;
|
|
|
|
|
class Type;
|
2014-10-30 00:32:14 +03:00
|
|
|
class ValueNode;
|
|
|
|
|
class ValueNodeManager;
|
2009-07-14 00:45:15 +04:00
|
|
|
|
|
|
|
|
|
2010-12-16 16:50:30 +03:00
|
|
|
class SourceLanguage : public BReferenceable {
|
2009-07-14 00:45:15 +04:00
|
|
|
public:
|
|
|
|
|
virtual ~SourceLanguage();
|
|
|
|
|
|
|
|
|
|
virtual const char* Name() const = 0;
|
|
|
|
|
|
|
|
|
|
virtual SyntaxHighlighter* GetSyntaxHighlighter() const;
|
|
|
|
|
// returns a reference,
|
|
|
|
|
// may return NULL, if not available
|
2012-11-06 15:22:06 +04:00
|
|
|
|
2014-10-26 00:19:38 +04:00
|
|
|
virtual status_t EvaluateExpression(const BString& expression,
|
Debugger: Rework expression parsing API.
ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.
CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.
ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.
Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.
2014-11-15 08:31:17 +03:00
|
|
|
ValueNodeManager* manager,
|
Debugger: Add basic support for types in expressions.
SourceLanguage/CLanguageFamily/ExpressionEvaluationJob:
- Add TeamTypeInformation parameter to EvaluateExpression() hook. Adjust
implementing subclasses and callers accordingly.
CLanguageExpressionEvaluator:
- Add class InternalVariableID for representing intermediate variables
generated while parsing an expression.
- When parsing an identifier, if we were passed in a type information object,
then first attempt to resolve the name as a type. If not matched, then fall
through to attempting to match it to a value node as before.
- When parsing an atom, check if it resulted in a type. If it did, and there
still remains more of the expression to parse, then parse the result to see
what value/variable to try to apply the typecast to. If the result is a
primitive, generate an appropriate internal variable + value node child for
it, otherwise use the target variable's child. Then, attempt to typecast it
as requested.
- Simplify _EatToken().
- If the final result of an expression is a type, configure the result object
accordingly.
As a result of all the above, an expression can now resolve to a type, allowing
the evaluator to take over the duties of parsing the desired type for a typecast
request in the variables view, and in addition, expressions themselves can now
contain typecasts, which opens up quite a few new possibilities.
2014-12-09 06:03:33 +03:00
|
|
|
TeamTypeInformation* info,
|
Debugger: Rework expression parsing API.
ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.
CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.
ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.
Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.
2014-11-15 08:31:17 +03:00
|
|
|
ExpressionResult*& _output,
|
|
|
|
|
ValueNode*& _neededNode);
|
2009-07-14 00:45:15 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#endif // SOURCE_LANGUAGE_H
|