Conversation
Rust 1.89 produces the following output: ``` error: unicode codepoint changing visible direction of text present in literal ... warning: allow(text_direction_codepoint_in_literal) is ignored unless specified at crate level --> rslib/i18n/src/generated.rs:7:10 | 7 | #![allow(text_direction_codepoint_in_literal)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This change fixes it. This ensures that some third-party crate that pulls in this code as library code (and thus isn't subject to the rust-toolchain file in this repo) doesn't hit this compilation error.
rillian
left a comment
rillian
left a comment
There was a problem hiding this comment.
This resolves the build failure for me.
It's unfortunate to widen the scope of the allow to files where the lint is actually useful, but the change was made to handle literals in macro expansions, which of course could come from other source files or indeed be generated at compile time, so provenance tracking is complicated.
Maybe a better fix would be to convert the text-direction markers to unicode escape sequences \u{202b}? Since this is a generated file, making the rtl strings unreadable is less of a problem.
| // Copyright: Ankitects Pty Ltd and contributors | ||
| // License: GNU AGPL, version 3 or later; http://www.gnu.org/licenses/agpl.html | ||
|
|
||
| #![allow(text_direction_codepoint_in_literal)] |
There was a problem hiding this comment.
Another linebreak between this and the following mod ... line would be more readable.
|
Thank you both! Agreed that auto-conversion during generation would be better, and I'll push an update that does so. |
3 participants
Rust 1.89 produces the following output for
cargo buildinrslib/i18n:This change fixes it.
This ensures that some third-party crate that pulls in this code as library code (and thus isn't subject to the rust-toolchain file in this repo) doesn't hit this compilation error.
... also the nixpkgs build of anki uses nixpkg's current rust version, not anki's
rust-toolchainversion 🙃