create dummy placeholder crate to prevent compiler from panicing

[megakorre]

This PR is to address the panic found in #105700.

There are 2 separate things going on with this panic.
First the code could not generate a dummy response for crate fragment types when it hits the recursion limit.
This PR adds the method to the trait implementation for DymmyResult to be able to create a dummy crate node.
This stops the panic from happening.

The second thing that is not addressed (and maybe does not need addressing? 🤷🏻)
is that when you have multiple attributes it ends up treating attributes that follow another as being the result of expanding the former (maybe there is a better way to say that). So you end up hitting the recursion limit. Even though you would think there is no expansion happening here.

If you did not hit the recursion limit the compiler would output that invalid_attribute does not exists. But it currently exits before the resolution step when the recursion limit is reached here.

[rustbot]

r? @michaelwoerister

(rustbot has picked a reviewer for you, use r? to override)

[michaelwoerister]

Thanks for the PR, @megakorre! Adding the make_crate implementation for DummyResult seems like a good idea.

However, I don't quite understand how a non-existing attribute interacts with the recursion limit. Maybe @petrochenkov knows what's exactly going on here? Maybe unknown attributes are speculatively assumed to be proc-macros and the recursion limit is checked before expansion?

[petrochenkov]

r? @petrochenkov

[petrochenkov]

The second thing that is not addressed ... is that when you have multiple attributes it ends up treating attributes that follow another as being the result of expanding the former

That's an expected behavior.
Before the first attribute is expanded the second attribute basically doesn't exist, it's just some token stream in the shape of an attribute, the first attribute can arbitrarily change or remove it.
So the actual post-expansion second attribute is indeed an expansion result of the first attribute.

[petrochenkov]

However, I don't quite understand how a non-existing attribute interacts with the recursion limit.
Maybe unknown attributes are speculatively assumed to be proc-macros and the recursion limit is checked before expansion?

All non-builtin attributes are expanded (maybe trivially) and contribute to the recursion count, including unresolved ones.
Even something like #![rustfmt::skip] is counted, because it needs to be resolved and trivially expanded.

[petrochenkov]

@bors r+

[bors]

📌 Commit 0fd2a70 has been approved by petrochenkov

It is now in the queue for this repository.

[bors]

⌛ Testing commit 0fd2a70 with merge 267cd1d...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 267cd1d to master...

[rust-timer]

Finished benchmarking commit (267cd1d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.