Avoid special casing of RustVec<String> (avoid rewriting it into RustVec<RustString>).
#1640
Conversation
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
See the PR conversation for more details why this change is desirable and safe/correct.
That would be from testing with an outdated version of
The specific nightly date shows up in the log:
|
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.
Motivation for this PR
The work toward supporting arbitrary
Tin generics would be easier if we didn't special-case specificTs. (I have a local chain of commits that builds on top of this PR, and ends up supportingVec<Box<T>>.)Safety/correctness of this PR
IIUC
::cxx::private::RustVec<T>:T: a fewusizes:cxx/src/rust_vec.rs
Line 15 in 32c81e0
Tsomewhere else in the FFI ABI (e.g. there are no extern/FFI APIs defined inrust_vec.rs)Therefore I don't understand why:
macro/src/expand.rsreplacesRustVec<String>withRustVec<RustString>(either "manually", or by callingexpand_extern_type)src/rust_vec.rsneeds to provide (viaimpl RustVec<RustString>) support for transmuting between values/references/etc ofVec<String>andRustVec<RustString>So, assuming my understanding above is correct, this PR stops special casing
Vec<String>.FWIW
RustVec<RustString>seems to come all the way from the original commit that added support forVec<String>: 33f56ad. And before this commitVec<String>was being rejected insyntax/check.rs. So maybe I am missing something here?Optional: unrelated
tests/uifailures in my local testingOne more (optional) question: any idea why I see some unexpected differences in
rustcoutput fortests/uiin my local testing viacargo test? For example, when I try with a recent nightly version (rustc 1.91.0-nightly (7ad23f43a 2025-09-09)) at a recentcxxrevision (c7cb3bf), thenTRYBUILD=overwrite cargo testgenerates the commit at anforowicz@09a5217 (which AFAICT only inserts a bit of whitespace in some testcases to indent error messages fromrustc), but GitHub CI then fails with https://github.com/anforowicz/cxx/actions/runs/17624407527/job/50077573425. FWIW I tried, but ultimately failed to check whichrustcversion is used by GitHub CI...