Implement a Symfony compatible Router object.

#1: 1835762_router.patch queued for re-testing.

+++ b/core/lib/Drupal/Core/Routing/Router.php
@@ -0,0 +1,136 @@
+  public function match($pathinfo) {
+    return $this->matchRequest(Request::create($pathinfo));
+  }

I'm not sure if we want to make this method actually work, or just make it fail hard as a note to not do that. Hm.

+++ b/core/lib/Drupal/Core/Routing/Router.php
@@ -0,0 +1,136 @@
+  /**
+   * Gets the RouteCollection instance associated with this Router.
+   *
+   * @return RouteCollection A RouteCollection instance
+   */
+  public function getRouteCollection() {
+    // Right now I have no idea what to return here. Let's just return something
+    // that complies with the docs.
+    return new RouteCollection();
+  }

Ugh. Which interface demands this? We should probably throw an exception here, since our route collections will be too big to return.

Also related: https://github.com/symfony/symfony/pull/5895

Nice.

I think we need to wire this into the DIC in this patch, which means having a noop Generator object that we can inject into it. So:

1) Create a UrlGeneratorInterface-compliant object that does nothing but throw exceptions if you try to use it.
2) Add a "router" service to the DIC that takes the current matcher and that new temp generator as dependencies.
3) Rewrite the DIC so that router object is what is passed to RouterListener, rather than passing the matcher directly.
4) Profit!

+++ b/core/lib/Drupal/Core/CoreBundle.php
@@ -99,7 +104,7 @@ public function build(ContainerBuilder $container) {
-      ->addArgument(new Reference('matcher'))
+      ->addArgument(new Reference('router'))

One change. This suggests we should be renaming matcher to router.matcher, for consistency with router.generator.

Once that's done, this is RTBC.

+++ b/core/lib/Drupal/Core/DependencyInjection/Compiler/RegisterMatchersPass.phpundefined
@@ -12,21 +12,21 @@
+ * Adds services tagged 'chained_matcher' to the 'router.matcher' service.

This a bit puzzling... When should one use a '_' in a service name and when should one use a '.' separator? Is perhaps 'chained_matcher' mis-named?

Thanks @g.oechsler for the explanation.

Domo arrigato, Mr. Testboto.

Can someone remind me why this is needed? It was my impression we could just subclass and override the one method that needed the generator but perhaps I'm mis-remembering. There's no explanation of why this is needed in the meta-issue either (except for the functional generator not being in yet, but that's not really a justification for committing a bunch of code that just throws exceptions when you try to use it).

OK let me put it a different way. What issue is this blocking that it can't wait on the generator patch and needs a dummy generator as a stop-gap?

We will need to do this in order to remerge with the upstream Symfony CMF Routing component, which we want to do: https://github.com/symfony-cmf/Routing/pull/30. That is not ready for us to do yet, of course, but is on the roadmap.

As is, no, this issue doesn't add any new functionality yet, and nothing would be harmed in the near term by eliminating the dummy generator and inlining all of the "don't use this yet" exceptions. That's why this is only "normal". :-)

However, I don't see a problem with lining things up for when we can finally bring together the various moving parts here, now that the path issue landed. I am not really wild about the idea of adding a generator, adding a router, merging url() into the generator, moving all of the path alias caching over into generator, refactoring url_rewrite_outbound_alter(), adding HttpCache, and possibly refactoring our code around what happens in CMF Routing all in one go. (I think that's all of the bits and pieces involved in this line of work.) I'd rather build toward that incrementally, so more people can be involved.

If you really want to just sit on it and do the entirety of it at once, fine, say so explicitly. But I respectfully disagree, if for no other reason than it reduces the number of people who are logistically able to be involved in it. (Plus, it will probably be harder to do.)

The all-at-once issue is here: #1874500: CMF-based Routing system

Closing this as a duplicate.