bug: ModuleSpecifier parsing on Windows

[bartlomieju]

It seems there are still problems with ModuleSpecifier parsing on Windows.

In #3344 I encountered problem on Windows CI where this path:

c:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\.tmpGMWvcR\\.deno.test.ts

was parsed as module specifier having c: scheme instead of file:// and I had to manually add file:// prefix doing dynamic import.

[axetroy]

Finally. I got this problem in #3346.

I am curious why CI failed under Windows.

I spent a lot of time exploring the problem.

[piscisaureus]

@bartlomieju

There is already logic to deal with this case:

deno/core/module_specifier.rs

Lines 172 to 190 in b9e5e4c

	fn specifier_has_uri_scheme(specifier: &str) -> bool {
	let mut chars = specifier.chars();
	let mut len = 0usize;
	// THe first character must be a letter.
	match chars.next() {
	Some(c) if c.is_ascii_alphabetic() => len += 1,
	_ => return false,
	}
	// Second and following characters must be either a letter, number,
	// plus sign, minus sign, or dot.
	loop {
	match chars.next() {
	Some(c) if c.is_ascii_alphanumeric() || "+-.".contains(c) => len += 1,
	Some(':') if len >= 2 => return true,
	_ => return false,
	}
	}
	}
	}

Can you figure out why it is not working?

[bartossh]

If something goes wrong it is here #L143. Url::from_file_path()) used here #L157 will panic if invalid path is passed. If this statement #L143 is not working as expected, We would be facing panic from this function: L129: Url::parse().

I am not able to fix it reliably, as I don't have access to Windows running machine. On Unix/Linux OS path encoding works fine.

What do you think ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.