transpile: tests: add .expect_unresolved_import instead of hardcoding libc#1719
transpile: tests: add .expect_unresolved_import instead of hardcoding libc#1719
.expect_unresolved_import instead of hardcoding libc#1719Conversation
…ng `libc` Also, we check that the error messages are as expected, too (meaning we actually run `rustc`). This also makes the `libc` tests more explicit.
…the expected unresolved import errors
kkysen
force-pushed
the
kkysen/transpile-snapshots-expect_unresolved_import
branch
from
a52145e to
becc685
Compare
fw-immunant
left a comment
fw-immunant
left a comment
There was a problem hiding this comment.
The general approach seems okay (not wonderful but Cargo is very resistant to helping us find the requisite information here), but I wasn't happy with some specifics. After addressing inline comments should be good to go.
|
|
||
| // Using rustc itself to build snapshots that reference crates (like libc) is difficult because we don't know | ||
| // the appropriate --extern libc=/path/to/liblibc-XXXXXXXXXXXXXXXX.rlib to pass. | ||
| // Skip for now, as we've already compared the literal text, |
There was a problem hiding this comment.
This comment ("skip for now") doesn't make sense anymore as compilation is no longer being skipped.
| Edition2021 => format!("error[E0433]: failed to resolve: could not find `{imported_crate}` in the list of imported crates"), | ||
| Edition2024 => format!("error[E0433]: cannot find `{imported_crate}` in the crate root"), | ||
| }; |
There was a problem hiding this comment.
It seems to me that we should parse the error code from the message and filter on that plus the mentioned library name. Hard-coding the whole error message seems very brittle.
There was a problem hiding this comment.
How do I parse the library name, though, without hardcoding the error message? I agree it could be brittle, but it'd have a simple error and then we update the error message needed, so it's a simple fix if it's ever changed, too.
There was a problem hiding this comment.
For the library name we do probably have to choose between something brittle (like hard-coding the error message) and something loose (like a simple string-contains check), but for the error code we should be able to parse in a somewhat robust way. E.g., in JSON output format it's given in its own "code" field. Even without JSON output, the "error[ENNNN]" prefix should be relatively stable.
2 participants
Also, we check that the error messages are as expected, too (meaning we actually run
rustc). This also makes thelibctests more explicit.This should also handle #1716.