Issue 1:
Version: symfony/validator 3.1.6, PHP 7.0.7

Background: I've been using the validator component for APIs for a long time (without forms though). One of the problems was that apart from the descriptive violation messages I wanted to return a fixed error name that can be handled by the application on the other end. I've achieved that by extending the base constraints and overriding the error messages (which means no descriptive message). I could live with that, waited for better times.

I noticed that the ConstraintViolation includes the ::getCode method now! Perfect for my little APIs. The code seems to be an UUID and each of the constraints includes a mapping to nice error names. UUIDs are usable but they are not the best UX for the end-programmer :).

The meat: The easiest way to get the error name would be to use Constraint::getErrorName method. This is where the problem is - in some cases the ConstraintViolation has the wrong Constraint attached. From the first look - it's the last tested constraint, not the one that failed.

I am aware that I am assuming the the ConstraintViolationInterface is actually a ConstraintViolation but IMO it's fair to assume when I'm using Symfony's validator component. Also the ConstraintViolation::getConstraint and Constraint::getErrorName methods are public so I am (I hope) not relying on some internal implementation details.

I am attaching a testcase for further illustration:

https://gist.github.com/pinkeen/7a3b6688efc3c493fc16807ac89d3a3f

Issue 2:
Hi,

It's possible that when calling the getConstraint() method on a ConstraintViolation generated by the Assert\Collection will return a different constraint than the Assert\Collection that caused the violation.

An example:

$data = ['email' => 'some.email@domain.com'];

$constraints = new Assert\Collection([
'password' => new Assert\NotBlank(),
'email' => new Assert\NotBlank(),
]);

$violations = $->validate($data, $constraints);

dump($violations);

Outputs

Symfony\Component\Validator\ConstraintViolationList {#2675
-violations: array:1 [
0 => Symfony\Component\Validator\ConstraintViolation {#2677
-message: "This field is missing."
--- >8 ---
-constraint: Symfony\Component\Validator\Constraints\Collection { --- >8 --- }
-code: 1
}
]
}

This is the correct and expected behavior. The constraint within the ConstraintViolation maps correctly to the constraint that caused the violation.

However, if we were to flip the order of field checks in the CollectionConstraint like so:

$constraints = new Assert\Collection([
'email' => new Assert\NotBlank(),
'password' => new Assert\NotBlank(),
]);

The output will look like this

Symfony\Component\Validator\ConstraintViolationList {#2675
-violations: array:1 [
0 => Symfony\Component\Validator\ConstraintViolation {#2677
-message: "This field is missing."
--- >8 ---
-constraint: Symfony\Component\Validator\Constraints\NotBlank { --- >8 --- }
-code: 1
}
]
}

The constraint in the ConstraintViolation is now mismatched from what the actual violation is.

Investigation

The reason this is happening is because of the way the context is passed into the validator when validating items in the Assert\Collection.

Since the context is passed in, the constraint is modified on it and this change persists during the validation of the rest of the fields in the Collection constraint. So if a field is missing the violation created will be created with the same context that no longer references the Collection constraint.

Proposed solution

cloneing the context in the inContext call appears to fix the problem. I haven't dived in deep enough though to fully understand if there would be other side effects.