summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Expressions] Add support of expressions evaluation in some object's contextAleksandr Urakov2019-02-051-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-1/+1
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Remove append parameter to FindGlobalVariablesPavel Labath2018-05-311-2/+2
| | | | | | | | | | | | | | | | | | | Summary: As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317, FindGlobalVariables does not properly handle the case where append=false. As this doesn't seem to be used in the tree, this patch removes the parameter entirely. Reviewers: clayborg, jingham, labath Reviewed By: clayborg Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere Differential Revision: https://reviews.llvm.org/D46885 Patch by Tom Tromey <ttromey@mozilla.com>. llvm-svn: 333639
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-47/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Use the DWARF linkage name when importing C++ methods.Davide Italiano2018-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | When importing C++ methods into clang AST nodes from the DWARF symbol table, preserve the DW_AT_linkage_name and use it as the linker ("asm") name for the symbol. Concretely, this enables `expression` to call into names that use the GNU `abi_tag` extension, and enables lldb to call into code using std::string or std::list from recent versions of libstdc++. See https://bugs.llvm.org/show_bug.cgi?id=35310 . It also seems broadly more robust than relying on the DWARF->clang->codegen pipeline to roundtrip properly, but I'm not immediately aware of any other cases in which it makes a difference. Patch by Nelson Elhage! Differential Revision: https://reviews.llvm.org/D40283 llvm-svn: 328658
* Fix crash exposed by r328025Pavel Labath2018-03-211-2/+3
| | | | | | | | | | | | | | | | The issue was that the ASTDumper was being passed a null pointer (because we did not create any declaration for the operator==). The crash was in logging code, so it only manifested it self if you ran the tests with logging enabled (like our bots do). Given that this is logging code and the rest of the debugger is fine with the declaration being null, I just make sure the logging code can handle it as well. Right now I just do the null check in ClangExpressionDeclMap, but if the ASTDumper class is meant to be a debugging/logging aid, then it might be a good idea move the check inside the class itself. llvm-svn: 328088
* [ExpressionParser] Re-implement r327356 in a less disruptive way.Davide Italiano2018-03-201-9/+0
| | | | | | | | | | | | Instead of applying the sledgehammer of refusing to insert any C++ symbol in the ASTContext, try to validate the decl if what we have is an operator. There was other code in lldb which was responsible for this, just not really exposed (or used) in this codepath. Also, add a better/more comprehensive test. <rdar://problem/35645893> llvm-svn: 328025
* [ExpressionParser] Fix crash when evaluating invalid expresssions.Davide Italiano2018-03-131-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Typical example, illformed comparisons (operator== where LHS and RHS are not compatible). If a symbol matched `operator==` in any of the object files lldb inserted a generic function declaration in the ASTContext on which Sema operates. Maintaining the AST context invariants is fairly tricky and sometimes resulted in crashes inside clang (or assertions hit). The real reason why this feature exists in the first place is that of allowing users to do something like: (lldb) call printf("patatino") even if the debug informations for printf() is not available. Eventually, we might reconsider this feature in its entirety, but for now we can't remove it as it would break a bunch of users. Instead, try to limit it to non-C++ symbols, where getting the invariants right is hopefully easier. Now you can't do in lldb anymore (lldb) call _Zsomethingsomething(1,2,3) but that doesn't seem to be such a big loss. <rdar://problem/35645893> llvm-svn: 327356
* Remove some dead code from ClangExpressionDeclMap.cppStephane Sezer2017-10-241-47/+3
| | | | llvm-svn: 316526
* Silence some "implicit conversion of string literal" warningsPavel Labath2017-10-171-2/+2
| | | | llvm-svn: 316038
* [ExpressionParser] Prefer isa<> to dyn_cast<>. NFCI.Davide Italiano2017-09-301-2/+1
| | | | | | The result type is unused anyway. llvm-svn: 314602
* [Expression parser] Setting to enable use of ExternalASTMergerSean Callanan2017-09-281-35/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This setting can be enabled like this at the target level: (lldb) settings set target.experimental.use-modern-type-lookup true This causes several new behaviors in the Clang expression parser: - It completely disables use of ClangASTImporter. None are created at all, and all users of it are now conditionalized on its presence. - It instead constructs a per-expression ExternalASTMerger, which exists inside Clang and contains much of the type completion logic that hitherto lived in ExternalASTSource, ClangExpressionDeclMap, and ClangASTImporter. - The expression parser uses this Merger as a backend for copying and completing types. - It also constructs a persistent ExternalASTMerger which is connected to the Target's persistent AST context. This is a major chunk of LLDB functionality moved into Clang. It can be tested in two ways: 1. For an individual debug session, enable the setting before running a target. 2. For the testsuite, change the option to be default-true. This is done in Target.cpp's g_experimental_properties. The testsuite is not yet clean with this, so I have not committed that switch. I have filed a Bugzilla for extending the testsuite to allow custom settings for all tests: https://bugs.llvm.org/show_bug.cgi?id=34771 I have also filed a Bugzilla for fixing the remaining testsuite failures with this setting enabled: https://bugs.llvm.org/show_bug.cgi?id=34772 llvm-svn: 314458
* [Expression Parser] Inhibit global lookups for symbols in the IR dynamic checksSean Callanan2017-09-261-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IR dynamic checks are self-contained functions whose job is to - verify that pointers referenced in an expression are valid at runtime; and - verify that selectors sent to Objective-C objects by an expression are actually supported by that object. These dynamic checks forward-declare all the functions they use and should not require any external debug information. The way they ensure this is by marking all the names they use with a dollar sign ($). The expression parser recognizes such symbols and perform no lookups for them. This patch fixes three issues surrounding the use of the dollar sign: - to fix a MIPS issue, the name of the pointer checker was changed from starting with $ to starting with _$, but this was not properly ignored; and - the Objective-C object checker used a temporary variable that did not start with $. - the Objective-C object checker used an externally-defined struct (struct objc_selector) but didn't need to. The patch also implements some cleanup in the area: - it reformats the string containing the Objective-C object checker, which was mangled horribly when the code was transformed to a uniform width of 80 columns, and - it factors out the logic for ignoring global $-symbols into common code shared between ClangASTSource and ClangExpressionDeclMap. Differential Revision: https://reviews.llvm.org/D38153 llvm-svn: 314225
* [Expression parser] Look up module symbols before hunting globallySean Callanan2017-05-161-100/+12
| | | | | | | | | | | | | | | | | | | When it resolves symbol-only variables, the expression parser currently looks only in the global module list. It should prefer the current module. I've fixed that behavior by making it search the current module first, and only search globally if it finds nothing. I've also added a test case. After review, I moved the core of the lookup algorithm into SymbolContext for use by other code that needs it. Thanks to Greg Clayton and Pavel Labath for their help. Differential Revision: https://reviews.llvm.org/D33083 llvm-svn: 303223
* Rename Error -> Status.Zachary Turner2017-05-121-4/+4
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* [DWARF parser] Produce correct template parameter packsSean Callanan2017-05-111-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Templates can end in parameter packs, like this template <class T...> struct MyStruct { /*...*/ }; LLDB does not currently support these parameter packs; it does not emit them into the template argument list at all. This causes problems when you specialize, e.g.: template <> struct MyStruct<int> { /*...*/ }; template <> struct MyStruct<int, int> : MyStruct<int> { /*...*/ }; LLDB generates two template specializations, each with no template arguments, and then when they are imported by the ASTImporter into a parser's AST context we get a single specialization that inherits from itself, causing Clang's record layout mechanism to smash its stack. This patch fixes the problem for classes and adds tests. The tests for functions fail because Clang's ASTImporter can't import them at the moment, so I've xfailed that test. Differential Revision: https://reviews.llvm.org/D33025 llvm-svn: 302833
* [Expression parser] Return both types and variablesSean Callanan2017-04-241-256/+249
| | | | | | | | | | | | | | | | | | | | | Many times a user wants to access a type when there's a variable of the same name, or a variable when there's a type of the same name. Depending on the precise context, currently the expression parser can fail to resolve one or the other. This is because ClangExpressionDeclMap has logic to limit the amount of information it searches, and that logic sometimes cuts down the search prematurely. This patch removes some of those early exits. In that sense, this patch trades performance (early exit is faster) for correctness. I've also included two new test cases showing examples of this behavior – as well as modifying an existing test case that gets it wrong. llvm-svn: 301273
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+1
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Expression evaluation for overloaded C functions (redux)Luke Drummond2016-12-191-5/+6
| | | | | | | | | | | | | | | | | | | This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored to properly substitute primitive types using a hook in the itanium demangler, and updated after the previous patch went stale The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement primitive type parameter as before but parses it using the FastDemangler, which has been modified to be able to notify clients of parse events (primitive types at this point). Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so that we don't try and resolve the same invalid candidate multiple times. Differential Revision: https://reviews.llvm.org/D27223 Subscribers: lldb-commits llvm-svn: 290117
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1874/+1771
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fix expression evaluation with operator newPavel Labath2016-08-151-5/+2
| | | | | | | | | | | | | | | | Summary: referencing a user-defined operator new was triggering an assert in clang because we were registering the function name as string "operator new", instead of using the special operator enum, which clang has for this purpose. Method operators already had code to handle this, and now I extend this to cover free standing operator functions as well. Test included. Reviewers: spyffe Subscribers: sivachandra, paulherman, lldb-commits Differential Revision: http://reviews.llvm.org/D17856 llvm-svn: 278670
* Removed the m_decl_objects map from ClangASTContext.Sean Callanan2016-05-231-1/+10
| | | | | | | | | | | | | m_decl_objects is problematic because it assumes that each VarDecl has a unique variable associated with it. This is not the case in inline contexts. Also the information in this map can be reconstructed very easily without maintaining the map. The rest of the testsuite passes with this cange, and I've added a testcase covering the inline contexts affected by this. <rdar://problem/26278502> llvm-svn: 270474
* Fixed a crash if a FunctionDecl couldn't be imported.Sean Callanan2016-05-191-3/+6
| | | | llvm-svn: 270097
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-291-4/+14
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 268083
* Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath2016-04-281-14/+4
| | | | | | | | | | $__lldb_expr." This reverts commit r267833 as it breaks the build. It looks like some work in progress got committed together with the actual fix, but I'm not sure which one is which, so I'll revert the whole patch and let author resumbit it after fixing the build error. llvm-svn: 267861
* Fix an inefficiency in the handling of $__lldb_local_vars in expressions.Jim Ingham2016-04-281-1/+2
| | | | | | | | | | | | | | The code in ClangExpressionDeclMap::FindExternalVisibleDecls figures out what the token means, and adds the namespace to the lookup context, but since it doesn't mark it as special in the search context, we go on to pass the name $__lldb_local_vars to the ASTSource for further lookup. Unless we've done our job wrong, those lookups will always fail, but the can be costly. So I added a bit to m_found & use that to short-circuit the lookup. <rdar://problem/25613384> llvm-svn: 267842
* Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-281-4/+14
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 267833
* Handle any persistent Decl in the Clang expression parser, not just types.Sean Callanan2016-03-191-41/+58
| | | | | | | | | | Persistent decls have traditionally only been types. However, we want to be able to persist more things, like functions and global variables. This changes some of the nomenclature and the lookup rules to make this possible. <rdar://problem/22864976> llvm-svn: 263864
* ExpressionParser: silence some GCC warningsSaleem Abdulrasool2016-02-151-1/+1
| | | | | | | Silence a -Wreorder warning about order of member initialization and a -Wqual-cast warning about casting away constness. NFC. llvm-svn: 260868
* Removed many JIT workarounds from IRForTarget.Sean Callanan2016-02-131-243/+49
| | | | | | | | | | | | | | | | | | | | | | Since IRExecutionUnit is now capable of looking up symbols, and the JIT is up to the task of generating the appropriate relocations, we don't need to do all the work that IRForTarget used to do to fixup symbols at the IR level. We also don't need to allocate data manually (with its attendant bugs) because the JIT is capable of doing so without crashing. We also don't need the awkward lldb.call.realName metadata to determine what calls are objc_msgSend, because they now just reference objc_msgSend. To make this work, we ensure that we recognize which symbols are extern "C" and report them to the compiler as such. We also report the full Decl of functions rather than just making up top-level functions with the appropriate types. This should not break any testcases, but let me know if you run into any issues. <rdar://problem/22864926> llvm-svn: 260768
* Take 2: Use an artifical namespace so that member vars do not hide local vars.Siva Chandra2016-02-051-4/+64
| | | | | | | | | | | | Summary: This relands r259810 with fix for failures on Mac. Reviewers: spyffe, tfiala Subscribers: tfiala, lldb-commits Differential Revision: http://reviews.llvm.org/D16900 llvm-svn: 259902
* Revert "Use an artifical namespace so that member vars do not hide local vars."Siva Chandra2016-02-041-64/+4
| | | | | | | | | | | | | | Summary: This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4. Reverting as it breaks a few tests on Mac. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16895 llvm-svn: 259823
* Use an artifical namespace so that member vars do not hide local vars.Siva Chandra2016-02-041-4/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While evaluating expressions when stopped in a class method, there was a problem of member variables hiding local variables. This was happening because, in the context of a method, clang already knew about member variables with their name and assumed that they were the only variables with those names in scope. Consequently, clang never checks with LLDB about the possibility of local variables with the same name and goes wrong. This change addresses the problem by using an artificial namespace "$__lldb_local_vars". All local variables in scope are declared in the "$__lldb_expr" method as follows: using $__lldb_local_vars::<local var 1>; using $__lldb_local_vars::<local var 2>; ... This hides the member variables with the same name and forces clang to enquire about the variables which it thinks are declared in $__lldb_local_vars. When LLDB notices that clang is enquiring about variables in $__lldb_local_vars, it looks up local vars and conveys their information if found. This way, member variables do not hide local variables, leading to correct evaluation of expressions. A point to keep in mind is that the above solution does not solve the problem for one specific case: namespace N { int a; } class A { public: void Method(); int a; }; void A::Method() { using N::a; ... // Since the above solution only touches locals, it does not // force clang to enquire about "a" coming from namespace N. } Reviewers: clayborg, spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16746 llvm-svn: 259810
* Better scheme to lookup alternate mangled name when looking up function address.Siva Chandra2016-01-071-4/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is relevant for inferiors compiled with GCC. GCC does not emit complete debug info for std::basic_string<...>, and consequently, Clang (the LLDB compiler) does not generate correct mangled names for certain functions. This change removes the hard-coded alternate names in ItaniumABILanguageRuntime.cpp. Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could not evaluate std::string methods (ex. std::string::length). After putting in the hard-coded names, one could evaluate them. However, it did not still enable one to call methods on, say for example, std::vector<string>. This change makes that possible. There is some amount of incompleteness in this change. Consider the following example: std::string hello("hello"), world("world"); std::map<std::string, std::string> m; m[hello] = world; One can still not evaluate the expression "m[hello]" in LLDB. Will address this issue in another pass. Reviewers: jingham, vharron, evgeny777, spyffe, dawn Subscribers: clayborg, dawn, lldb-commits Differential Revision: http://reviews.llvm.org/D12809 llvm-svn: 257113
* Fix scope-based lookup when more than one function is found.Dawn Perchik2015-12-121-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | When multiple functions are found by name, lldb removes duplicate entries of functions with the same type, so the first function in the symbol context list is chosen, even if it isn't in scope. This patch uses the declaration context of the execution context to select the function which is in scope. This fixes cases like the following: int func(); namespace ns { int func(); void here() { // Run to BP here and eval 'p func()'; // lldb used to find ::func(), now finds ns::func(). } } Reviewed by: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15312 llvm-svn: 255439
* Made the ClangASTImporter into a shared pointer, eliminating a race condition.Sean Callanan2015-11-101-12/+12
| | | | | | | | | | | | | | | It used to be a unique pointer, and there could be a case where ClangASTSource held onto a copy of the pointer but Target::Destroy destroyed the unique pointer in the mean time. I also ensured that there is a validity check on the target (which confirms that a ClangASTImporter can be generated) before the target's shared pointer is copied into ClangASTSource. This race condition caused a crash if Target::Destroy was called and then later the target objecct was deleted. llvm-svn: 252665
* Fixed some issues with reporting "this" when the current function is not listedSean Callanan2015-10-231-36/+37
| | | | | | | | | in DWARF as a member of a class, but it has a "this" parameter. Specifically, *this needs to have the LLDB expression added as a method. This fixes TestWithLimitDebugInfo. llvm-svn: 251151
* Add PersistentVariableDelegate to handle language-specific dematerialization.Sean Callanan2015-10-031-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
* Eliminated redundant "constructors" for ClangExpressionVariable. ↵Sean Callanan2015-10-011-33/+29
| | | | | | | | | | | | | The ClangExpressionVariable::CreateVariableInList functions looked cute, but caused more confusion than they solved. I removed them, and instead made sure that there are adequate facilities for easily adding newly-constructed ExpressionVariables to lists. I also made some of the constructors that are common be generic, so that it's possible to construct expression variables from generic places (like the ABI and ValueObject) without having to know the specifics about the class. llvm-svn: 249095
* Made Target hold a map of languages to TypeSystems, and added some accessors.Sean Callanan2015-10-011-1/+1
| | | | | | | | Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-1/+1
| | | | | | | | | | the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-0/+2225
There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
OpenPOWER on IntegriCloud