html5ever failing to compile on perf

[Mark-Simulacrum]

html5ever is failing to compile in perf with this error; I'm not sure if this is something we need to fix in source or if it's a regression.

cc @petrochenkov

error: macro-expanded `macro_export` macros from the current crate cannot be referred to by absolute paths
  --> /home/alex/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/string_cache-0.2.29/src/lib.rs:71:13
   |
71 |     pub use atom;
   |             ^^^^
   |
note: the macro is defined here
  --> /tmp/.tmpFazpQK/target/debug/build/string_cache-589ae806702507d8/out/atom_macro.rs:2:1
   |
2  | / macro_rules! atom {
3  | | (\"sdev\") => { $crate::Atom { unsafe_data: 0x2 } };
4  | | (\"onstart\") => { $crate::Atom { unsafe_data: 0x100000002 } };
5  | | (\"overflow\") => { $crate::Atom { unsafe_data: 0x200000002 } };
...  |
127| | (\"stroke-miterlimit\") => { $crate::Atom { unsafe_data: 0x4f400000002 } };
127| | }
   | |_^

error: aborting due to previous error

[petrochenkov]

Unfortunately, this restriction is necessary for #52234 to work soundly without causing much worse issues like #53053 (comment).
The best short-term solution is to fix this in source.

[petrochenkov]

This is an expected "can't make an omelette" regression from enabling macro modularization, more or less.
string_cache-0.2.29 was unlucky to hit a very specific set of circumstances under which this new error has to be reported.

[petrochenkov]

Hmm, I think we can report this error as a deprecation lint for some time though.

[Mark-Simulacrum]

Leaving this open to track the compat lint fix.

[Mark-Simulacrum]

Hm, so the atom macro and the atom module are public API for the string-cache crate so it's unclear to me that we can easily fix this in source unless I'm missing something -- @petrochenkov, do you have any guidance on the best way to apply a fix?

[petrochenkov]

Turned into a deprecation lint in #53653