refactor: create fish-future-feature-flags crate#12494
Draft
danielrainer wants to merge 6 commits intofish-shell:masterfrom
Draft
refactor: create fish-future-feature-flags crate#12494danielrainer wants to merge 6 commits intofish-shell:masterfrom
fish-future-feature-flags crate#12494danielrainer wants to merge 6 commits intofish-shell:masterfrom
Conversation
added 6 commits
March 1, 2026 00:26
The `msguniq` call for deduplicating the msgids originating from Rust previously did not get a header entry (empty msgid with msgstr containing metadata). This works fine as long as all msgids are ASCII-only. But when a non-ASCII character appears in a msgid, `msguniq` errors out without a header specifying the encoding. To resolve this, add the header to the input of this `msguniq` invocation and then remove the header again using sed to prevent duplicating it for the outer msguniq call at the end of the file.
This time, functions for decoding `wstr` into various types and the `ToCString` trait are extracted. Part of the wider goal of slimming down the main library to improve incremental build performance and reduce dependency cycles.
Previously, we chose the ellipsis character/string based on the locale. We now assume a UTF-8 locale, and accordingly always use the Unicode HORIZONTAL ELLIPSIS U+2026 `…`. When this was changed, some of the logic for handling different ellipsis values was left behind. It no longer serves a purpose, so remove it. The functions returning constants are replaced by constants. Since the ellipsis as a `wstr` is only used in a single file, make it a local const there and define it via the `ELLIPSIS_CHAR` const. Put the `ELLIPSIS_CHAR` definition into `fish-widestring`, removing the dependency of `fish-wcstringutil` on `fish-common`, helping future extraction efforts. One localized message contains an ellipsis, which was inserted via a placeholder, preventing translators from localizing it. Since the ellipsis is a constant, put it directly into the localized string.
This is done in preparation for extracting this file into its own crate.
Another step in splitting up the main library crate. At the moment, this breaks tests outside of the new crate, since the crate changes behavior depending on whether the `test` config is active, but tests outside the crate get the version with `test` disabled.
0f0bddf to
c10d04a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Another step in splitting up the main library crate.
At the moment, this breaks tests outside of the new crate, since the
crate changes behavior depending on whether the
testconfig is active,but tests outside the crate get the version with
testdisabled.I tried to extract this because some other code I want to extract depends on it. However, in the current state it does not work. I haven't looked much into the semantics of the code, but the core problem is that
#[cfg(test)]does not work across crate boundaries. Maybe we can resolve this by removing the behavioral difference in this case. Otherwise it might be possible to hack around it via some feature setting viabuild.rs, but that does not seem very robust.Putting it out there in case someone has an idea of how to deal with this problem.
Stacked on #12493, but only to reduce merge conflicts.