Move breakpoint resolver down into Features

[mhutch]

Moves the IBreakpointResolutionService implementations from the VisualStudio layer down into the EditorFeatures layer. They don't have VS dependencies, and the interface is already defined in this layer. This gives VSMac the option to use this service without code duplication.

Brings IProximityExpressionsService and its implementations along because it doesn't really have any reason to be in the higher layer either and could also potentially be useful.

[tmat]

Do these types have dependencies on the Editor? Just wondering if we can move them even lower, to the Features layer.

[mhutch]

I think that would be possible but I'm not sure whether it matters 🙂

[CyrusNajmabadi]

@mhutch Generally, this is useful because it really helps understand the layering. It also prevents people from unintentionally taking on dependencies later that aren't appropriate (at least without some discussion).

PLacing this in features would mean this couldn't accidently take an editor dependency without people strongly considering if that was an ok idea or not.

[jasonmalinowski]

Yeah, we should move this to Features at least, since we really don't want this accidentally taking an editor dependency.

[mhutch]

Okay, moved it!

[mhutch]

Fixed conflicts. Failures do not appear to be related. @jasonmalinowski what do i need to do to move this along?

[jasonmalinowski]

@jinujoseph can we get @mhutch a PR buddy for this one?

[jinujoseph]

@tmat can you help buddy this forward

[mhutch]

bump?

[mhutch]

bump

[tmat]

Looks good modulo a couple of nits. We need to be careful with merging though as this will break F# and possibly TypeScript. We need to coordinate.

@sharwell @jasonmalinowski @TIHan @amcasey

How about

1. creating a branch off of master-vs-deps with this change, produce a signed build
2. create VS insertion PR from that branch
3. create corresponding change in TS and F# and insert them in the same PR [2]

We can avoid the branch if we are willing to block our insertions while waiting on TS and F# changes.

[amcasey]

FYI @minestarks

[tmat]

test this please

[minestarks]

@tmat speaking for TypeScript: please, pretty please can you consider doing this breaking change in two stages, where you duplicate the API, mark the old one as obsolete, and THEN after we've moved over, remove the old API? Coordinated insertions are have been a routine headache for us. Let's discuss over e-mail if you wish.

[mhutch]

Bump :)

[tmat]

@mhutch Still on my radar. We are working on a system that will allow us to make changes like this that affect multiple components across VS easier. Once we have that system in place we will merge this change.

[tmat]

@mhutch The code base is now ready for this change. I have resolved conflicts.

[tmat]

@dotnet/roslyn-ide Anybody wants to take a look?