Adding more supported operators to DIL breaks tests in `DWIMPrint` and
`lldb-dap`, which shouldn't be simply adjusted for new DIL capabilities.
They act as a check for the boundaries of what subset of expressions
`DWIMPrint` and `lldb-dap` expect to be evaluated when using
`GetValueForVariableExpressionPath` function. With this patch, the
caller can now pick a mode that limits the expressions DIL can evaluate,
which ensures the expected preexisting behavior. More operators can now
be safely added to DIL, which can still be evaluated by DIL when using
`frame var` command or the API call with Full mode selected (or not
specified at all).
DIL will only attempt evaluating expressions that contain operations
allowed by a selected mode:
- Simple: identifiers, operators: '.'
- Legacy: identifiers, integers, operators: '.', '->', '*', '&', '[]'
- Full: everything supported by DIL
This patch introduces `ScalarLiteralNode` without any uses by other
nodes yet. It also includes lexing and parsing for integer and floating
point numbers.
Reapplies #152308 with a fix.
This patch introduces `ScalarLiteralNode` without any uses by other
nodes yet. It also includes lexing and parsing for integer and floating
point numbers.
This attempts to fix the issues with the original PR (#151605), updating
the DIL code for handling array subscripting to more closely match and
handle all the casees from the original 'frame var' implementation. The
first PR did not include special-case code for objc pointers, which
apparently caused a test failure on the green-dragon buildbot. Hopefully
this PR, which includes the objc pointer special code, fixes that issue.
This updates the DIL code for handling array subscripting to more
closely match and handle all the cases from the original 'frame var'
implementation. Also updates the DIL array subscripting test. This
particularly fixes some issues with handling synthetic children, objc
pointers, and accessing specific bits within scalar data types.
This test has been flaky on Linaro's Windows on Arm bot and I was
able to reproduce it within 10 or so runs locally.
When it fails it's because we failed to read the value of int_arr[100].
When that happens the memory looks like this:
```
[0x0000006bf88fd000-0x0000006bf8900000) rw- <-- sp (0x0000006bf88ffe20)
[0x0000006bf8900000-0x0000025fec900000) --- <-- int_arr[100] (0x0000006bf8900070)
```
The first region is the stack and the stack pointer is pointing
within that region, as expected.
The second region is where we are trying to read int_arr[100] from
and this is not mapped because we're trying to read above the start
of the stack.
Sometimes the test passes I think because ASLR / DYNAMICBASE moves
the start of the stack down enough so there is some readable memory
at the top.
https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase?view=msvc-170
Note "Because ASLR can't be disabled on ARM, ARM64, or ARM64EC
architectures,
/DYNAMICBASE:NO isn't supported for these targets.". Which means on this
bot,
the layout is definitely being randomised.
We don't need to be testing indexes this large. So I've changed the two
test indexes to 3 (1 beyond the end) and 10 (a larger distance beyond
the end).
We know that index 42 always worked on the bot, so 10 should be fine,
and
did not fail locally.
This has been flaky on Linaro's Windows on Arm bot, failing
with errors all along these lines:
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\commands\frame\var-dil\basics\ArraySubscript\TestFrameVarDILArraySubscript.py", line 56, in test_subscript
self.expect_var_path("int_arr[100]", True, type="int")
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\commands\frame\var-dil\basics\ArraySubscript\TestFrameVarDILArraySubscript.py", line 15, in expect_var_path
value_dil = super().expect_var_path(expr, value=value, type=type)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2589, in expect_var_path
value_check.check_value(self, eval_result, str(eval_result))
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 301, in check_value
test_base.assertSuccess(val.GetError())
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2597, in assertSuccess
self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
AssertionError: 'read memory from 0x68119c00b0 failed (0 of 4 bytes read)' is not success
I think this is because we are trying to read off of the top of the
stack which is unmapped memory on Windows.
I have a fix I'm going to put in review shortly.
