Can you provide a reproducing case ? The service definition you gave above does not trigger this for me (are you sure it refers to this service ? this cryptic service id looks like one generated by the XMLFileLoader when defining a service without an id)

@stof very sure, the error goes away if I change the ID attrib to class attrib.

@dkarlovi Can you create a small example application that allows to reproduce the error?

@xabbuh sure.

Same error message with a malformed services.xml
Once deleted the tag from an incomplete deleted service, the error goes away.

@mitridates A reproducible project would ease helping you.

@xabbuh I haven't forgotten to do it, just waiting for the month to roll over to free up some time :)

The XML loader creates randomly named services for anonymous declarations. Generating inlined definitions would fix the issue. I don't think there is any other way.

@nicolas-grekas can't it use some better naming? Like anonymous.liip_imagine.imagick.setMetadataReader.argument0 or something? Check for ID / Class or some other identifier? Even origin XML file name would be somewhat helpful.

Backtracking from this error would have been mission impossible.

As inline definitions are now a first-class citizen in Symfony since 3.4 (rather than being things which are not guaranteed to work fine all the time), I think we might now refactor the XML loader to stop turning anonymous services into named ones (but it may have to wait for 4.2 due to the feature freeze depending on how we consider this refactoring).

So, do you even need a test case then if the issue is understood?

My case is not about of an anonymous service, only a wrong tag. I deleted the code but this example of services.xml throws the message as RuntimeException The definition for "1_c4eemeg" has no class. If you intend to inject... instead of an validArgumentException Unable to parse file ....
The tag <service/> is parsed as a service.

<?xml version="1.0" encoding="UTF-8" ?> <container xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://symfony.com/schema/dic/services" xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd"> <services> <service/> </services> </container>

Well, you still have an anonymous service (without any config here), as a <service> tag is precisely what defines a service in the XML file.

@nicolas-grekas here is my proposal for a next version (probably 4.2 due to the feature freeze):

• keep inline services as actual inline definition instead of turning them into named private services in the XML loader). This could even allow us to perform a better validation as a few settings don't make sense on inline services (like the id in the snippet of the issue description)
• deprecate the definition of top-level anonymous services (which is supported only in XML). Symfony 5.0 could then even mark the id attribute as required in the XSD for top-level services and forbidden for inline ones (using separate XSD types for them; even though they would share most things, they are different)

Good news, top level services with no "id" are forbidden since 4.0, see

Keeping inline services as inline definition should be doable, maybe for 4.1 also.
Anyone willing to give it a try? @dkarlovi maybe?

I would, but haven't studied the DI component until now, could use some pointers

Everything is in

Alright. I'll have some time tomorrow so will try it.

@stof @nicolas-grekas, looking at this a bit, I mostly understand how it works currently, but this is a bit puzzling:

keep inline services as actual inline definition

What does "inline definition" mean in this jargon? Do I create the Definition instance with parseDefinition and then assign it as the argument of its parent?

Yes, we mean Definition instances instead of Reference