-
Notifications
You must be signed in to change notification settings - Fork 14k
Closed
Description
When running ./x.py test on the big-endian s390x platform, I see the following error:
---- [ui] src/test/rustdoc-ui/unknown-renamed-lints.rs stdout ----
diff of stderr:
14 --> $DIR/unknown-renamed-lints.rs:7:9
15 |
16 LL | #![deny(rustdoc::x)]
- | ^^^^^^^^^^ help: did you mean: `rustdoc::all`
+ | ^^^^^^^^^^ help: did you mean: `rustdoc`
18
Investigating this in more detail shows that this happens due to a combination of several factors:
- The suggestion is generated by the
no_lint_suggestionroutine incompiler/rustc_lint/src/context.rs, which does
let groups = self.lint_groups.keys().copied().map(Symbol::intern);
let lints = self.lints.iter().map(|l| Symbol::intern(&l.name_lower()));
let names: Vec<Symbol> = groups.chain(lints).collect();
let suggestion = find_best_match_for_name(&names, Symbol::intern(&name_lower), None);
- The
find_best_match_for_nameroutine returns (in this case) the name out ofnamesthat has the lowest Levenshtein distance from the target name. - However, both
rustdocandrustdoc::allare at the same distance fromrustdoc::x. In this case, the name that occurs earlier in thenameslist is returned - so the order of that vector matters. self.lint_groups.keys()returns the elements oflint_groupsin the order of the hash values of theFxHashMap. However, the associatedHasherin therustc_hashcrate does not guarantee stable values across different architecture; in particular, the same string will hash to different values on a big-endian platform vs. a little-endian platform.- As a result, for this particular test case, the order of
rustdocandrustdoc::allinnamesis different based on host endianness, and therefore the diagnostic emitted depends on host endianness as well.
It seems to me this is not ideal. So I'm wondering:
- Should the members of
namesbe sorted according to some criteria to ensure deterministic diagnostics across platforms? - As an aside:
rustdocis considered "deprecated" whilerustdoc::allis not - should this routine ever suggest a deprecated name in the first place?
I've implemented a fix that simply ignores deprecated members of lint_groups, which fixes the test case for me. Not sure if this is really the correct solution - I'd be happy to help implement and test other approaches as well.
Metadata
Metadata
Assignees
Labels
No labels