Fix bug in _SimpleUri.resolve.

Fix bug in _SimpleUri.resolve.

In some cases it didn't follow our non-RFC behavior for resolving a relative
path on top of another relative path.

Fixes issue #27447
BUG= http://dartbug.com/27447
R=eernst@google.com

Committed: https://github.com/dart-lang/sdk/commit/9bd4406d4ba9db9cda26089136d5cc16415125b0

[Lasse Reichstein Nielsen, 2016-09-29 11:38:13]

lrn@google.com changed reviewers:
+ eernst@google.com, floitsch@google.com

[eernst, 2016-09-29 12:28:50]

LGTM, with a couple of requests for more detailed commenting.

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart
File sdk/lib/core/uri.dart (right):

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart#n...
sdk/lib/core/uri.dart:4343: int backCount = 0;
It would help to document this variable. Is it something like this?:
// Number of "../" in `refUri.substring(0, refStart)` that
// we haven't eliminated by matching up with the end of `baseUri`.

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart#n...
sdk/lib/core/uri.dart:4366: }
This while loop seems to cut off segments starting with slashes (like
"/some-path-element"). It would be nice to have a comment hinting on the main
purpose of the loop, not just the corner case. (It might seem obvious to you
right now, but it gets a bit less obvious when trying to do a fixed point
operation of the partially known meaning of several variables).

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart#n...
sdk/lib/core/uri.dart:4381: // over, so don't insert a "/" - that would make the
result absolute.
Would be nice to have an explicit "this is the case where we differ from RFC
3986" here (ah! - we used to have that, too).

https://codereview.chromium.org/2374253004/diff/20001/tests/corelib/uri_test....
File tests/corelib/uri_test.dart (right):

https://codereview.chromium.org/2374253004/diff/20001/tests/corelib/uri_test....
tests/corelib/uri_test.dart:219: // Absoluyte path, not scheme or authority.
Typos: '..uy..', 'not' --> 'no'?

[Lasse Reichstein Nielsen, 2016-09-29 12:58:31]

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart
File sdk/lib/core/uri.dart (right):

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart#n...
sdk/lib/core/uri.dart:4343: int backCount = 0;
On 2016/09/29 12:28:49, eernst wrote:
> It would help to document this variable. Is it something like this?:
> // Number of "../" in `refUri.substring(0, refStart)` that
> // we haven't eliminated by matching up with the end of `baseUri`.

Done.

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart#n...
sdk/lib/core/uri.dart:4366: }
On 2016/09/29 12:28:49, eernst wrote:
> This while loop seems to cut off segments starting with slashes (like
> "/some-path-element"). It would be nice to have a comment hinting on the main
> purpose of the loop, not just the corner case. (It might seem obvious to you
> right now, but it gets a bit less obvious when trying to do a fixed point
> operation of the partially known meaning of several variables).

Done.

https://codereview.chromium.org/2374253004/diff/20001/sdk/lib/core/uri.dart#n...
sdk/lib/core/uri.dart:4381: // over, so don't insert a "/" - that would make the
result absolute.
That is what it says right above (look for RFC-3986).

I've reordered the logic here so it's easier to understand.

[Lasse Reichstein Nielsen, 2016-09-29 13:00:46]

Description was changed from

==========
Fix bug in _SimpleUri.resolve.

In some cases it didn't follow our non-RFC behavior for resolving a relative
path on top of another relative path.

Fixes issue #27447
BUG= http://dartbug.com/27447
==========

to

==========
Fix bug in _SimpleUri.resolve.

In some cases it didn't follow our non-RFC behavior for resolving a relative
path on top of another relative path.

Fixes issue #27447
BUG= http://dartbug.com/27447
R=eernst@google.com

Committed:
https://github.com/dart-lang/sdk/commit/9bd4406d4ba9db9cda26089136d5cc16415125b0
==========

[Lasse Reichstein Nielsen, 2016-09-29 13:00:48]

Committed patchset #4 (id:60001) manually as
9bd4406d4ba9db9cda26089136d5cc16415125b0 (presubmit successful).