Two improvements to disallowed_*

[smoelius]

The improvements are as follows:

• Remove an unnecessary compile-flags directive in tests/ui-toml/toml_disallowed_methods/conf_disallowed_methods.rs
• Support replacements as suggested by @mitsuhiko in disallowed_methods should allow for reasons in the toml file #7609 (comment)

---

changelog: support replacements in disallowed_methods

[rustbot]

r? @Centri3

rustbot has assigned @Centri3.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Centri3]

Can you add tests to ensure the spaces change works on disallowed_types? DisallowedPath is used there too, but it does its own parsing to get the DefId of types.

[bors]

☔ The latest upstream changes (presumably 627363e) made this pull request unmergeable. Please resolve the merge conflicts.

[smoelius]

@Centri3 Just so that we are on the same page, I am assuming I have done all I can with this PR. Please let me know if I have misunderstood.

Also, thanks very much for reviewing. 🙏

[Centri3]

Sorry, forgot to say. I haven't looked closely at the new changes but this definitely feels like too much when we could just have two for now. One where replacements are allowed and one where they aren't. Maybe with a shared trait to make the implementation less cumbersome and annoying... I don't know. Using const generics is definitely less understandable than that even if it's not exactly ideal. No solution really feels ideal, actually.

[smoelius]

@Centri3 Is this better?

I pushed on top of the const generic stuff, but can squash once we arrive at a solution.

[Centri3]

I think I've found a pretty good solution: Using const generics is okay and probably ideal if we use type aliases. Let's do that vs this struct solution. Unfortunate it took a while for me :P

My main concern with const generics was how they had to be specified everywhere and how it's not immediately clear what it is.

With this, I think we can have just the enum afaik.

[smoelius]

I think I've found a pretty good solution: Using const generics is okay and probably ideal if we use type aliases.

Is this what you are suggesting, or something more elaborate?

type DisallowedPathWithoutReplacement = DisallowedPath<false>;

[Centri3]

Ah, forgot to respond; yes pretty much.

[smoelius]

The most recent commit undoes most of the commit before it (including getting rid of the AmendDiag trait) and adds a type alias like in #13669 (comment).

Could you please tell me what else is needed?

[Centri3]

Just two small things. Happy with this version

[Centri3]

I do find this to be an odd implementation detail. I assume this is just a workaround to both derive Deserialize and have our const generic, but imo it adds way too much confusion. It should be clearer that it's not to be used elsewhere and ideally wouldn't be here at all.

Let's make this private.

[smoelius]

I made the enum private and I added a comment that it is not meant to be used outside of this file.

I assume this is just a workaround to both derive Deserialize and have our const generic, but imo it adds way too much confusion. It should be clearer that it's not to be used elsewhere and ideally wouldn't be here at all.

I'm not wed to this approach. Can you think of another way to do this?

[smoelius]

Or is there something I could do to make the code more clear?

[Centri3]

Current approach is ok, just talking about a perfect world. Making it private is more than good enough

LGTM in this state 👍 I'll look one last time tomorrow and will likely merge then.