.

Improve some names

See the new description of the diff for the updates

nits

• Moved the test to gtest. It's much better this way and I learned gtest
• Changed the API. Some notes:

Very good idea!

improve description

address comments`

I agree with the implementation.
I also find no way notify the IDE that the user has switched to a different thread or frame in the console, and I actually think it's better this way.

fix typos

Thanks for the heads up. I think I got a false impression of how comments after accept vs requesting changes work in this repo.

address comments

address comments

clang-format

Noise, for some reason I can't run clang-format as part of arc lint on this device.
I'm running it manually anyway

Addressed comments

Some included changes:

• Removed the "source" element if the "breakpoint" object returned in breakpoint events
• CreateBreakpoint now accepts an optional line number, which is used as fallback if no location is valid
• Added a test that asserts breakpoints in dynamically loaded libraries

cleanup

Account for dynamically loaded libraries and update the logic for breakpoint events

address comments

Added a stop command invocation in the test

address comments

merge the commits of this diff

address comments

cleanup

His last activity was in Jun 2017. I hope he's still around.

update commit message

With https://reviews.llvm.org/D76470, targets created by lldb-vscode by default are inheriting the debugger's environment. I don't need this change anymore.
We can work on providing a flag that disables that default behavior, but that can also be set by an initCommand if someone really needs it.

Thanks for the notice. I apologize for not doing everything correctly. I'm still trying to understand how all the different piece of the system works and I end up learning from the things that fail...

Use clayborg's wording. Thanks, milord.

TBH I'd prefer to have consistency across all these options regardless of how the target is launched. That means modifying the defaults of the target settings that can be specified via launch.json arguments.

fix test failing with python3

I pushed this by mistake, but I've just reverted the commit.

I pushed this by mistake, but I've just reverted the commit.

further simplify code. Sorry for the noise

simplify code

test pass now

improve comment

I added some tests cases to show why I used "settings set target.inherit-env".

apply last suggestions

Thanks a lot, guys. I learned a lot from you doing this patch :)

Now using the latest SBEnvironment API

rebase

fix grammar

• Added both kinds of APIs we were discussing. It will come handy for all different kind of usages
• Added an SBEnvironment API for SBLaunchInfo, which will be used in https://reviews.llvm.org/D74636
• Address all sorts of comments

Well, I think I'll implement both kind of accessors in the API to account for all possible cases

support python2.7

address comments

improve a comment

Using the new SBEnvironment class

address comments

Addressed Greg's comments.

add a test

Thanks for the review!

address comments

As we discussed privately, some remote connections use a mutiplexor socket that doesn't die when the debug session ends.

format

.

address comments≈

Thanks a lot for the feedback! I was thinking about adding features to this class as needed, but definitely I should make this API be more like a map

format

The original intention of this is to have any working environment, as quite often complex programs require many environment variables that are common to most processes. Having the user specify each of those is a bit too much to ask for, and they are complaining because of this. That said, just using the platform's environment would be enough to have something working. And it the extreme case when other specific env vars are needed, then the user can specify them by hand.

Regarding implementation: