Don't miss adding some tests please.

@nicolas-grekas I found out that my changes are breaking tests. First of all, I'll fix them, and then provide new tests for this feature.

I have added some tests for this feature, so I think this PR is ready to review.

I am afraid that making this change would be a BC break as it would completely change the current behaviour. To make this more clear I have started to write some tests for the class which should illustrate the current behaviour (see #36584) which to depend on can totally make sense from my point of view.

@xabbuh when you call atPath() twice, the second call adds the path to the result of the first (The first call: data.foo, The second - data.foo.bar). I think this is the wrong behavior. In my case, the paths are stored in array:

['data.foo', 'data.bar']

and the addViolation() adds validation to the foo and bar fields.

If we don’t need this behavior, there is another way. Create a new method - andPath(string $path). in this case, atPath() will work the way it works, and andPath() will add another path.

when you call atPath() twice, the second call adds the path to the result of the first (The first call: data.foo, The second - data.foo.bar). I think this is the wrong behavior.

Well, at least that's the documented behaviour (and we thus cannot change it without breaking BC):

The passed path will be appended to the current property path of the execution context.

This sentence is part of the docblock of ConstraintViolationBuilderInterface::atPath():

If we don’t need this behavior, there is another way. Create a new method - andPath(string $path). in this case, atPath() will work the way it works, and andPath() will add another path.

What I would then find confusing is that calling addViolation() would not only add one violation (as I would expect from this name), but several ones. Maybe another solution could be to make it easy to reuse a constraint violation builder for another constraint.

Rereading the linked issue I think a rather simple solution would be to use clone before calling atPath().

@ABGEO Are you interested in trying @xabbuh suggestion?

@fabpot there is nothing to do there. I think we can close this PR and related issue.