Looks great! Thanks Adrian. My understanding is that DW_OP_piece is still incomplete, right?

@aprantl should be ready for another pass.

• [FastIsel] Update comments to reflect reality.

Adrian's comments.

This is very good, go for it. Should we do the same for Swift? cc: @aprantl
For the future, please CC: me directly on these kind of changes if you want my review, as I might miss them otherwise.

LGTM

In D72413#1813630, @teemperor wrote:

The C++ expression parser will probably behave incredibly incorrectly without a persistent state but before this patch it just crashed, so I think this is good to go.

@teemperor what do you think?

In D72413#1812464, @aprantl wrote:

Should we merge this like that, or is there a better way of doing this?

Raphael and Jim should look at the expression evaluator bits.

LGTM.

We don't need this.

This looks good to me.

LGTM!

Did you test on swift?

This is not a bad idea after all. Let me see if I can cook something reasonable without getting burned.

Ideally -- if we're able to make this a callback in the language plugins, we don't need this patch at all.

In D71310#1778534, @jingham wrote:

Adrian and I talked about this some more. Apparently the idea was that you have some type Foo and you want to look for some error state in instances of that type (Foo::a + Foo::b < 10). So you add a Type Validator for Foo that does this check, and every time lldb prints a variable of type Foo, it will run the Validator on it, and if it fails validation, then the printer will print an ! at the beginning of the printing, and also there's an SB API to get whether the Value passed the validator.

So then you could just debug along, and either look for the ! in the printing, or add a stop hook that checks the Validator result on all locals, and if you ever saw the error state, you would know to investigate further. That's actually a pretty neat idea.

The current state of the code is that there is actually no way to add a Type Validator. To be really useful, there would need to be a way to create a scripted validator, so the Python bindings and some command/SB API to register the validator.

The implementation is a little cut-and-paste too. It shares all the same options with the Synthetic child provider & Summaries (skips pointers, cascade, etc.) but I don't think you would ever want a type validator that would only validate references to a type, but not the type itself. And then the implementation is very cut & paste. So I'm fine with deleting this for now, but maybe adding it as an interesting project idea to the Projects page - with a reference to the hash of this commit as a starting point?

It's a neat idea but it's also been 5 years now and it was never made useful...

LGTM, in the same vein as D71231.

LGTM.

This one looks fine -- can you please check that this patch applied on swift still produces something reasonable for mixed obj-C/swift formatters?
My guess is that it will, and you probably just need to update some tests.

This looks fine, I wonder whether it's worth testing [how easy it's to test, that is]

Nevermind, I found a better way.

Please don't merge this yet. I'm mostly trying to understand if this is dead code or not.

LGTM.

We've been off all the past week. I'll circle back with Jim about this once I get to the office.

I'm committing this for you.

In D70324#1755704, @labath wrote:

[This is probably not the right patch, as the last run on that bot still doesn't have this commit.]

My understanding is that all pexpect tests are failing on that bot and are skipped with @skipIfAsan. Probably this one needs to be skipped too. @teemperor was trying to reproduce some of those failures locally and failed... Maybe that bot is cursed...

Hey Jordan, it looks like some of the changes to TestEditLine [or adjacent to it] broke the sanitized build on macOS.
Can I ask you to take a look? Thanks

LGTM

Thanks for writing this up!

Thanks again for your contribution!

While I review this, can you create a corresponding change to swift.org which tests this? [I don't think we have a way of triggering this from pure Obj-C, but I may be wrong].

In D68179#1745614, @tetsuo-cpp wrote:

Thanks for looking at this. I will need someone to commit it for me.
However, I've been having issues with the test suite on my MacBook. check-lldb-unit works for me but check-llvm and check-lldb are hitting issues because of something wrong with my environment. So I'll need to sort this out first to verify that I haven't broken anything before it's committed. I'm hoping to spend some time this weekend to debug my setup.

Thanks for adding the tests. I took a look at the patch and it seems fine to me. Do you need somebody to commit this for you?
@jingham or @labath may want to have another look.

Nice!

LGTM.

Go for it.

If I fix your patch by removing the semicolon, I see three tests failing.

uh, how can this possibly work?

I'll commit this for you later tonight.

LGTM. @aprantl / @vsk ? Do you need somebody to commit this for you?

This patch looks good to me.

[if you probably replace opt -ipconstprop with opt -ipsccp in the tests you'll stumble upon the cases I pointed out.

LGTM.

LGTM

What are you trying to accomplish here?

LGTM