[EventDispatcher] Added assertion.
merged branch jakzal/2.0-event (PR #7038)

This PR was merged into the 2.0 branch.

Commits
-------

4ce9ac3 [EventDispatcher] Added assertion.

Discussion
----------

[EventDispatcher] Added assertion

re #7023, I think it actually makes sense to add an assertion here. It reveals the intent of the test (listener is not removed).

---------------------------------------------------------------------------

by vicb at 2013-02-10T11:32:06Z

I don't think the assertion would fail with the former code, would it ?

---------------------------------------------------------------------------

by vicb at 2013-02-10T11:34:30Z

I mean an error would be generated even before the assertion.

---------------------------------------------------------------------------

by jakzal at 2013-02-10T11:37:05Z

Yes, it would fail before getting to the assertion with: *Object of class Closure could not be converted to int*.

However, this is something good to test for (and document - test is a documentation). We're not checking if type is taken into account in other tests. This test might still fail if code inside removeListener() changed.

---------------------------------------------------------------------------

by vicb at 2013-02-10T11:42:29Z

I don't really understand your point and think it is a bit useless here but I am not against your change - I don't argue that test is doc though.

---------------------------------------------------------------------------

by jakzal at 2013-02-10T15:38:09Z

Assertion is indeed useless for the bug you discovered and fixed. I think it's still worth to have it there for  other reason:
* test readability and completeness - with an assertion it's more clear that we don't expect the listener to be removed with the `removeListener()` call if passed argument doesn't match the one added before

If you still don't see my point just close this PR :)

---------------------------------------------------------------------------

by vicb at 2013-02-10T17:34:35Z

What I mean is that you are unit testing php and it is not a job for sf. So it is not strictly required but as it doesn't hurt, let's merge your change.

Jakub Zalas <notifications@github.com> wrote:

>Assertion is indeed useless for the bug you discovered and fixed. I
>think it's still worth to have it there for  other reason:
>* test readability and completeness - with an assertion it's more clear
>that we don't expect the listener to be removed with the
>`removeListener()` call if passed argument doesn't match the one added
>before
>
>If you still don't see my point just close this PR :)
>
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/symfony/symfony/pull/7038#issuecomment-13351469
[DependencyInjection] fixed tests (refs #7017)
[Process] Fix regression introduced in #6620 / 880da01c49a9255f5022ab7e18bca38c18f56370, fixes #7082
merged branch Seldaek/regressionfix (PR #7102)

This PR was merged into the 2.0 branch.

Commits
-------

179cd58 [Process] Fix regression introduced in #6620 / 880da01c49a9255f5022ab7e18bca38c18f56370, fixes #7082

Discussion
----------

[Process][2.0] getcwd failure fix

Fix regression introduced in #6620
Fixes #7082

For reference, here is the current behavior I saw:

PHP 5.4.11, windows:

```
5.4.11\php.exe -r "chdir('c:\\'); var_dump(getcwd()); $p = proc_open('pwd', [['pipe', 'r'], ['pipe', 'w'], ['pipe', 'w']], $pipes, null); var_dump(stream_get_contents($pipes[1]));"
string(3) "C:\\"
string(14) "/c/Users/seld\n"
```

(I use pwd which is a unix util so it dumps a funny path, but don't look at that)

PHP 5.5alpha4, windows (seems fixed):

```
5.5.0a4\php.exe  -r "chdir('c:\\'); var_dump(getcwd()); $p = proc_open('pwd', [['pipe', 'r'], ['pipe', 'w'], ['pipe', 'w']], $pipes, null); var_dump(stream_get_contents($pipes[1]));"
string(3) "C:\"
string(3) "/c\n"
```

PHP 5.3.10, ubuntu:

```
php -r "chdir('/'); var_dump(getcwd()); \$p = proc_open('pwd', array(array('pipe', 'r'), array('p
ipe', 'w'), array('pipe', 'w')), \$pipes, null); var_dump(stream_get_contents(\$pipes[1]));"
string(1) "/"
string(2) "/\n"
```

Since the permission issue that #6620 originally was fixing is most likely not gonna happen on windows, this seems like a safe enough compromise. Ideally a check for PHP<5.5 should be introduced, but I would like to be sure it's been fixed and is not just a lucky coincidence (/cc @PierreJoye)

I would recommend merging fast and maybe adding the version check later, since it breaks composer create-project on windows. The workaround being: cd in the dir and run `composer install` again to finalize the project setup.

---------------------------------------------------------------------------

by vicb at 2013-02-17T20:12:17Z

Thanks @Seldaek !

Would you mind creating an issue for the version check so that it doesn't get lost ?

---------------------------------------------------------------------------

by Seldaek at 2013-02-18T10:43:56Z

@vicb done.

---------------------------------------------------------------------------

by vicb at 2013-02-18T11:45:16Z

thanks !
[DomCrawler] lowered parsed protocol string (fixes #6986)
merged branch cloppy/Dom-Crawler-fix (PR #7127)

This PR was merged into the 2.0 branch.

Commits
-------

cb03074 [DomCrawler] lowered parsed protocol string (fixes #6986)

Discussion
----------

[DomCrawler] lowered parsed protocol string (fixes #6986)

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6986
| License       | MIT
| Doc PR        | symfony/symfony-docs#123

Are UTs needed for this?
[Form] Fixed "label" option to accept the value "0"
merged branch bschussek/issue6862 (PR #7150)

This PR was merged into the 2.0 branch.

Commits
-------

f8812b2 [Form] Fixed "label" option to accept the value "0"

Discussion
----------

[Form] Fixed "label" option to accept the value "0"

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6862
| License       | MIT
| Doc PR        | -

@fabpot: This commit will cause troubles when merging 2.0 into 2.1 and up. Tell me if you need help upon conflict resolution.
[Console] Fixed comment
merged branch DenisGorbachev/2.0 (PR #7198)

This PR was merged into the 2.0 branch.

Commits
-------

3be3dde [Console] Fixed comment

Discussion
----------

[Console] Fixed comment

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -