-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: windows #2132
fix: windows #2132
Conversation
8aa5c3f
to
38e3d6b
Compare
38e3d6b
to
2c83fd1
Compare
Upon more investigation it seems the tests fail because we try to match run tests using |
Where exactly? Where do we perform comparisons with "identifiers"? |
@mattsse In foundry/forge/src/multi_runner.rs Line 287 in 9dcc095
In the multirunner tests we collect these results in a foundry/forge/src/multi_runner.rs Line 488 in 9dcc095
|
I see, but this is only an issue with the test, right? because on windows, everything should be \? we can update the tests with either See https://doc.rust-lang.org/std/path/constant.MAIN_SEPARATOR.html I think it's also worthwhile adding a function to ArtifactId that does convert slashes, via path-slash crate |
If that's the case then I think that might be our bug for the other Windows issues - we use dunce::canonicalize heavily which will turn \ into / but that's not the case for some ethers-rs stuff. At least that's my current thinking, will have to investigate more. Ideally we'd support both but that also means settling on one version. Afaik Windows supports both |
89b8184
to
2bb6cac
Compare
Currently failing things:
|
c1137c6
to
8236acc
Compare
@@ -99,7 +99,7 @@ impl ScriptArgs { | |||
|
|||
let mut extra_info = ExtraLinkingInfo { | |||
no_target_name, | |||
target_fname, | |||
target_fname: target_fname.clone(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This clone is for a better error message further down.. Once we clean up linking we should consider cleaning up the targetting logic in script as well (and other commands that take <path>:<name>
)
let (path, name) = extra | ||
.target_fname | ||
.rsplit_once(':') | ||
.expect("The target specifier is malformed."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out the bug was staring us in the face all along - on Windows paths obviously contain :
so the path we compared with in this branch was literally just the drive letter on Windows lmao
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
omg
@@ -210,22 +211,25 @@ impl ScriptArgs { | |||
|
|||
// We received `contract_path:contract_name` | |||
if let Some(path) = contract.path { | |||
let path = dunce::canonicalize(&path)?; | |||
let path = | |||
dunce::canonicalize(&path).wrap_err("Could not canonicalize the target path")?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some error message improvements
cli/src/utils.rs
Outdated
let is_windows = cfg!(windows) && !Paint::enable_windows_ascii(); | ||
let env_colour_disabled = std::env::var("NO_COLOR").is_ok(); | ||
if is_windows || env_colour_disabled { | ||
if is_test || is_windows || env_colour_disabled { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Windows doesn't support color out of the box so instead of replacing every ANSI escape code in our fixtures I just opted to disable colors in tests. I think this is OK, if the colors are off it's not critical and we'd know easily anyway
}); | ||
|
||
impl OutputExt for process::Output { | ||
#[track_caller] | ||
fn stdout_matches_path(&self, expected_path: impl AsRef<Path>) -> &Self { | ||
let expected = fs::read_to_string(expected_path).unwrap(); | ||
let expected = IGNORE_IN_FIXTURES.replace_all(&expected, ""); | ||
let expected = IGNORE_IN_FIXTURES.replace_all(&expected, "").replace('\\', "/"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because ArtifactId::identifier
does not contain a canonicalized path
format!( | ||
"{}={}/", | ||
src, | ||
dest.trim_end_matches('/') | ||
.replace('/', std::str::from_utf8(&[std::path::MAIN_SEPARATOR as u8]).unwrap()) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remappings from Config
on Windows seem to use Windows paths, except if part of the path is from another remapping (see the config tests for examples).
The remappings we use to compare in tests however are not canonicalized. I'm not sure what the best fix is given how flexible remappings are
forgetest!(canhandle_direct_imports_into_src, |prj: TestProject, mut cmd: TestCommand| { | ||
// Tests that direct import paths are handled correctly | ||
// | ||
// NOTE(onbjerg): Disabled for Windows -- for some reason solc fails with a bogus error message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really have NO IDEA at all what is going on here. "Invalid implicit conversion from struct Bar memory to struct Bar memory"????
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol that makes no sense lol
let's keep this ignored for windows
"nested/=lib/nested-lib/lib/nested/".parse().unwrap(), | ||
// NOTE(onbjerg): For some reason a part of this remapping was not normalized on | ||
// Windows | ||
format!("{}another-lib/src/", remapping_str("another-lib/", "lib/nested-lib/lib/")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what's going on here... I think it might be because the path contains other remappings? It's a bit hard to follow
"nested/=lib/nested-lib/lib/nested/".parse().unwrap(), | ||
// NOTE(onbjerg): For some reason a part of this remapping was not normalized on | ||
// Windows | ||
format!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
struct PrettyString(String); | ||
|
||
impl PartialEq for PrettyString { | ||
fn eq(&self, other: &PrettyString) -> bool { | ||
self.0.lines().eq(other.0.lines()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoids having to replace \r\n
with \n
Finally! I reverted the workflow back to its original state(ish), but a successful run can be found here: https://github.com/foundry-rs/foundry/runs/7165826844 (note: long testing time is cus I accidentally removed the cache step lol) |
cli/test-utils/src/script.rs
Outdated
let testdata = format!("{}/../../testdata", env!("CARGO_MANIFEST_DIR")); | ||
std::fs::hard_link( | ||
std::fs::copy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard links from some non-temp directory to a temp directory is considered a violation of filesystem boundaries on Windows, so we have to copy instead 🙄
This vastly simplifies fixtures, especially for platforms that do not support color
On Windows hard links cannot cross filesystem boundaries, which temp folders are considered.
5912625
to
ca7b393
Compare
fcfa280
to
bcdfc87
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome!
not sure what to do about the remapping_str
.
perhaps easiest solution would be using path_slash::PathBufExt
to convert all slashes in the remappings?
rustflags = [ | ||
# Increases the stack size to 10MB, which is | ||
# in line with Linux (whereas default for Windows is 1MB) | ||
"-C", "link-arg=/STACK:10000000", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL
/// | ||
/// NOTE: This probably should be unnecessary, and remappings should probably | ||
/// be canonicalized. | ||
pub fn remapping_str(src: &str, dest: &str) -> String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we use paths-slash crate here instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should do that in ethers-solc instead - not sure if using / would break anything internally, but I think at a minimum it would be safe to use / in Display
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that makes sense!
forgetest!(canhandle_direct_imports_into_src, |prj: TestProject, mut cmd: TestCommand| { | ||
// Tests that direct import paths are handled correctly | ||
// | ||
// NOTE(onbjerg): Disabled for Windows -- for some reason solc fails with a bogus error message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol that makes no sense lol
let's keep this ignored for windows
High level lgtm. Wonder if we should think about it more or ship it and let Windows users tell us what works well and what doesn't? |
@gakonst I think ship and figure it out, there are probably other bugs lurking but it's hard to find |
After the svm-rs fix we now have new failing tests. Also adds a new test for #2092 and #2085, and will (eventually) fix those bugs
Closes #2078, closes #2092, closes #2085