Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

/// Unwraps the value. /// <del> /// # Safety /// /// This function is unsafe because this thread or another thread may currently be /// inspecting the inner value. /// </del> /// # Examples /// /// ```


Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

/// /// let uc = UnsafeCell::new(5); /// <del> /// let five = unsafe { uc.into_inner() }; </del> <ins> /// let five = uc.into_inner(); </ins> /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> pub unsafe fn into_inner(self) -> T { </del> <ins> pub fn into_inner(self) -> T { </ins> self.value } }


Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

#[inline] #[stable(feature = "atomic_access", since = "1.15.0")] pub fn into_inner(self) -> bool { <del> unsafe { self.v.into_inner() != 0 } </del> <ins> self.v.into_inner() != 0 </ins> } /// Loads a value from the bool.


Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

#[inline] #[stable(feature = "atomic_access", since = "1.15.0")] pub fn into_inner(self) -> *mut T { <del> unsafe { self.p.into_inner() } </del> <ins> self.p.into_inner() </ins> } /// Loads a value from the pointer.


Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

#[inline] #[$stable_access] pub fn into_inner(self) -> $int_type { <del> unsafe { self.v.into_inner() } </del> <ins> self.v.into_inner() </ins> } /// Loads a value from the atomic integer.


Question: From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

let &(ref first_arm_pats, _) = &arms[0]; let first_pat = &first_arm_pats[0]; let span = first_pat.span; <del> span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern"); </del> <ins> struct_span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern") .span_label(span, &format!("irrefutable pattern")) .emit(); </ins> }, hir::MatchSource::ForLoopDesugar => {


Question: From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

tcx.sess.add_lint(lint::builtin::MATCH_OF_UNIT_VARIANT_VIA_PAREN_DOTDOT, pat.id, pat.span, msg); } else { <del> span_err!(tcx.sess, pat.span, E0164, "{}", msg); </del> <ins> struct_span_err!(tcx.sess, pat.span, E0164, "{}", msg) .span_label(pat.span, &format!("not a tuple variant or struct")).emit(); </ins> on_error(); } };


Question: From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

.emit(); } Err(CopyImplementationError::HasDestructor) => { <del> span_err!(tcx.sess, span, E0184, </del> <ins> struct_span_err!(tcx.sess, span, E0184, </ins> "the trait `Copy` may not be implemented for this type;  <del> the type has a destructor"); </del> <ins> the type has a destructor") .span_label(span, &format!("Copy not allowed on types with destructors")) .emit(); </ins> } } });


Question: From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

fn bar(foo: Foo) -> u32 { match foo { Foo::B(i) => i, //~ ERROR E0164 <ins> //~| NOTE not a tuple variant or struct </ins> } }


Question: From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

fn main() { let irr = Irrefutable(0); while let Irrefutable(x) = irr { //~ ERROR E0165 <ins> //~| irrefutable pattern </ins> // ... } }


Question: From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

// except according to those terms. #[derive(Copy)] //~ ERROR E0184 <ins> //~| NOTE Copy not allowed on types with destructors //~| NOTE in this expansion of #[derive(Copy)] </ins> struct Foo; impl Drop for Foo {


Question:
From: src/test/compile- E0263 needs a span_label, updating it from: To: Bonus: underline and label the previous declaration:
I'm on it.

let lifetime_j = &lifetimes[j]; if lifetime_i.lifetime.name == lifetime_j.lifetime.name { <del> span_err!(self.sess, lifetime_j.lifetime.span, E0263, "lifetime name `{}` declared twice in  the same scope", lifetime_j.lifetime.name); </del> <ins> struct_span_err!(self.sess, lifetime_j.lifetime.span, E0263, "lifetime name `{}` declared twice in the same scope", lifetime_j.lifetime.name) .span_label(lifetime_j.lifetime.span, &format!("declared twice")) .span_label(lifetime_i.lifetime.span, &format!("previous declaration here")) .emit(); </ins> } }


Question:
From: src/test/compile- E0263 needs a span_label, updating it from: To: Bonus: underline and label the previous declaration:
I'm on it.

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { } //~ ERROR E0263 </del> <ins> fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { //~^ ERROR E0263 //~| NOTE declared twice //~| NOTE previous declaration here } </ins> fn main() {}


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

"tempfile", "thorin-dwp", "tracing", <ins> "windows 0.46.0", </ins> ] [[package]]


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

version = "0.30.1" default-features = false features = ["read_core", "elf", "macho", "pe", "unaligned", "archive", "write"] <ins> [target.'cfg(windows)'.dependencies.windows] version = "0.46.0" features = ["Win32_Globalization"] </ins>


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

if !prog.status.success() { let mut output = prog.stderr.clone(); output.extend_from_slice(&prog.stdout); <del> let escaped_output = escape_string(&output); </del> <ins> let escaped_output = escape_linker_output(&output, flavor); </ins> // FIXME: Add UI tests for this error. let err = errors::LinkingFailed { linker_path: &linker_path,


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

} } <ins> #[cfg(not(windows))] fn escape_linker_output(s: &[u8], _flavour: LinkerFlavor) -> String { escape_string(s) } /// If the output of the msvc linker is not UTF-8 and the host is Windows, /// then try to convert the string from the OEM encoding. #[cfg(windows)] fn escape_linker_output(s: &[u8], flavour: LinkerFlavor) -> String { // This only applies to the actual MSVC linker. if flavour != LinkerFlavor::Msvc(Lld::No) { return escape_string(s); } match str::from_utf8(s) { Ok(s) => return s.to_owned(), Err(_) => match win::locale_byte_str_to_string(s, win::oem_code_page()) { Some(s) => s, // The string is not UTF-8 and isn't valid for the OEM code page None => format!("Non-UTF-8 output: {}", s.escape_ascii()), }, } } /// Wrappers around the Windows API. #[cfg(windows)] mod win { use windows::Win32::Globalization::{ GetLocaleInfoEx, MultiByteToWideChar, CP_OEMCP, LOCALE_IUSEUTF8LEGACYOEMCP, LOCALE_NAME_SYSTEM_DEFAULT, LOCALE_RETURN_NUMBER, MB_ERR_INVALID_CHARS, }; /// Get the Windows system OEM code page. This is most notably the code page /// used for link.exe's output. pub fn oem_code_page() -> u32 { unsafe { let mut cp: u32 = 0; // We're using the `LOCALE_RETURN_NUMBER` flag to return a u32. // But the API requires us to pass the data as though it's a [u16] string. let len = std::mem::size_of::<u32>() / std::mem::size_of::<u16>(); let data = std::slice::from_raw_parts_mut(&mut cp as *mut u32 as *mut u16, len); let len_written = GetLocaleInfoEx( LOCALE_NAME_SYSTEM_DEFAULT, LOCALE_IUSEUTF8LEGACYOEMCP | LOCALE_RETURN_NUMBER, Some(data), ); if len_written as usize == len { cp } else { CP_OEMCP } } } /// Try to convert a multi-byte string to a UTF-8 string using the given code page /// The string does not need to be null terminated. /// /// This is implemented as a wrapper around `MultiByteToWideChar`. /// See <https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar> /// /// It will fail if the multi-byte string is longer than `i32::MAX` or if it contains /// any invalid bytes for the expected encoding. pub fn locale_byte_str_to_string(s: &[u8], code_page: u32) -> Option<String> { // `MultiByteToWideChar` requires a length to be a "positive integer". if s.len() > isize::MAX as usize { return None; } // Error if the string is not valid for the expected code page. let flags = MB_ERR_INVALID_CHARS; // Call MultiByteToWideChar twice. // First to calculate the length then to convert the string. let mut len = unsafe { MultiByteToWideChar(code_page, flags, s, None) }; if len > 0 { let mut utf16 = vec![0; len as usize]; len = unsafe { MultiByteToWideChar(code_page, flags, s, Some(&mut utf16)) }; if len > 0 { return utf16.get(..len as usize).map(String::from_utf16_lossy); } } None } } </ins> fn add_sanitizer_libraries(sess: &Session, crate_type: CrateType, linker: &mut dyn Linker) { // On macOS the runtimes are distributed as dylibs which should be linked to // both executables and dynamic shared objects. Everywhere else the runtimes


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

<ins> // build-fail // compile-flags:-C link-arg=märchenhaft // only-msvc // error-pattern:= note: LINK : fatal error LNK1181: // normalize-stderr-test "(s*|n)s*= note: .*n" -> "$1" pub fn main() {} </ins>


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

<ins> error: linking with `link.exe` failed: exit code: 1181 | = note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj' error: aborting due to previous error </ins>


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }


Question:
A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.

target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,


Question:
Full code: Given a smart pointer, which only works on types implementing the trait or on trait objects, such that is allowed to coerce to , and the corresponding implementation : Applying the operator on two will try to coerce them to , even though this isn't needed. This is an issue since coercion moves the original pointer. Removing the implementation lets the code build, which means that the coercion is not needed. As , if the is restricted to pointers with identical types (), then no coercion occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Seems related to
I've discovered a simpler reproduction: Curiously, when you just do , there's no problem. The overeager coercion can only occur in the presence of type inference. It also only occurs when the is non-parametric, i.e. not written like this: Likely because this allows to coerce to itself, hiding the issue. This also explains why it hasn't come up in the stdlib, because no type tries to coerce to a specific unsized type; it's all parametric.
The original code compiles with no errors today, so seems like E-needstest.
I think I tested the wrong thing; not E-needstest.
The linked reproduction from no longer fails to compile; is this fixed?
This is fixed but does need a test, though I think it could also be closed without a test, since it's been open for so long there's probably already coverage :thinking:
I think we should add the test just to be sure.
claim

<ins> // check-pass #![feature(coerce_unsized, unsize)] use std::marker::Unsize; use std::ops::CoerceUnsized; struct Foo<T: ?Sized>(Box<T>); impl<T> CoerceUnsized<Foo<dyn Baz>> for Foo<T> where T: Unsize<dyn Baz> {} struct Bar; trait Baz {} impl Baz for Bar {} fn main() { let foo = Foo(Box::new(Bar)); let foobar: Foo<Bar> = foo; } </ins>


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

impl<'a> CheckAttrVisitor<'a> { fn check_inline(&self, attr: &ast::Attribute, target: Target) { if target != Target::Fn { <del> span_err!(self.sess, attr.span, E0518, "attribute should be applied to function"); </del> <ins> struct_span_err!(self.sess, attr.span, E0518, "attribute should be applied to function") .span_label(attr.span, &format!("requires a function")) .emit(); </ins> } }


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

let mut conflicting_reprs = 0; for word in words { let name = match word.name() { Some(word) => word, None => continue, }; <del> let message = match &*name { </del> <ins> let (message, label) = match &*name { </ins> "C" => { conflicting_reprs += 1; if target != Target::Struct && target != Target::Union && target != Target::Enum { <del> "attribute should be applied to struct, enum or union" </del> <ins> ("attribute should be applied to struct, enum or union", "a struct, enum or union") </ins> } else { continue }


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

// can be used to modify another repr hint if target != Target::Struct && target != Target::Union { <del> "attribute should be applied to struct or union" </del> <ins> ("attribute should be applied to struct or union", "a struct or union") </ins> } else { continue }


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

"simd" => { conflicting_reprs += 1; if target != Target::Struct { <del> "attribute should be applied to struct" </del> <ins> ("attribute should be applied to struct", "a struct") </ins> } else { continue }


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

"isize" | "usize" => { conflicting_reprs += 1; if target != Target::Enum { <del> "attribute should be applied to enum" </del> <ins> ("attribute should be applied to enum", "an enum") </ins> } else { continue } } _ => continue, }; <del> span_err!(self.sess, attr.span, E0517, "{}", message); </del> <ins> struct_span_err!(self.sess, attr.span, E0517, "{}", message) .span_label(attr.span, &format!("requires {}", label)) .emit(); </ins> } if conflicting_reprs > 1 { span_warn!(self.sess, attr.span, E0566,


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

} } hir::TyTypeof(ref _e) => { <del> span_err!(tcx.sess, ast_ty.span, E0516, "`typeof` is a reserved keyword but unimplemented"); </del> <ins> struct_span_err!(tcx.sess, ast_ty.span, E0516, "`typeof` is a reserved keyword but unimplemented") .span_label(ast_ty.span, &format!("reserved keyword")) .emit(); </ins> tcx.types.err } hir::TyInfer => {


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

fn main() { let x: typeof(92) = 92; //~ ERROR E0516 <ins> //~| reserved keyword </ins> }


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

// except according to those terms. #[repr(C)] //~ ERROR E0517 <ins> //~| requires a struct, enum or union </ins> type Foo = u8; #[repr(packed)] //~ ERROR E0517 <ins> //~| requires a struct </ins> enum Foo2 {Bar, Baz} #[repr(u8)] //~ ERROR E0517 <ins> //~| requires an enum </ins> struct Foo3 {bar: bool, baz: bool} #[repr(C)] //~ ERROR E0517 <ins> //~| requires a struct, enum or union </ins> impl Foo3 { }


Question: From: src/test/compile- E0516 needs a span_label, updating it from: To:

// except according to those terms. #[inline(always)] //~ ERROR E0518 <ins> //~| requires a function </ins> struct Foo; #[inline(never)] //~ ERROR E0518 <ins> //~| requires a function </ins> impl Foo { }


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question: From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


Question:
I get an ICE on an older project, when running cargo doc - when documenting glium v0.13.5 specifically - with the current nightly build. The issue seems to be the line in of that glium version The glium crate is linked in the backend::glutin_backend module. The compiler warns about PR , but at the moment it compiles fine, only generating docs doesn't work. A minimal example, that generates the same behaviour, when documenting, is: : Backtrace for minimal example:
Introduced between and ()
cc looks like this points to , any ideas here?
Hmm, that's odd -- I'll investigate.
Fixed in .

// If the resolution doesn't depend on glob definability, check privacy and return. if let Some(result) = self.try_result(&resolution, ns) { return result.and_then(|binding| { <del> if self.is_accessible(binding.vis) && !is_disallowed_private_import(binding) { </del> <ins> if self.is_accessible(binding.vis) && !is_disallowed_private_import(binding) || binding.is_extern_crate() { // c.f. issue #37020 </ins> Success(binding) } else { Failed(None)


Question:
I get an ICE on an older project, when running cargo doc - when documenting glium v0.13.5 specifically - with the current nightly build. The issue seems to be the line in of that glium version The glium crate is linked in the backend::glutin_backend module. The compiler warns about PR , but at the moment it compiles fine, only generating docs doesn't work. A minimal example, that generates the same behaviour, when documenting, is: : Backtrace for minimal example:
Introduced between and ()
cc looks like this points to , any ideas here?
Hmm, that's odd -- I'll investigate.
Fixed in .

<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![allow(private_in_public)] mod foo { pub mod bar { extern crate core; } } mod baz { pub use foo::bar::core; } fn main() { baz::core::cell::Cell::new(0u32); } </ins>


Question:
When I configured with and ran , my install ended up in .
Seems to be because of which was apparently for . If the cannot be removed, then converting to absolute path before installing might work.
I think this is still an issue with rustbuild, but should be somewhat easy to fix.. I think we just want to call canonicalize on the paths here: Does that sound correct to you? If so, this is E-easy and E-mentor (by me).
I believe so!
I can take a crack at this one if nobody else has started on it yet.
Go ahead! Let us know if there's anything we can do to help you.
Just an update - still working on this, just got buried in a move. Will try to get it knocked out this week.
are there any unit-like tests that run against the install scripts? or do they just get tested as part of the full build?
No unfortunately I don't think we test this step at all on CI :(
canonicalizing the prefix breaks when prefix is a symbolic link. e.g., /usr/local -/some/other/location Now if you want to install to <destdir/usr/local, everything goes to <destdir/some/other/location instead with many files including references to /some/other/location internally. Now when I want to change the /usr/local sym link (in my case, the underlying location is a shared NFS mount point) to point to /a/different/location that contains the rust install, all the references to /some/other/location are wrong - leaving the best remaining option to recompile rust (and that's painful) on each occurrence where the underlying path pointed to by <prefixis different. There must be a better way to solve the relative path issue than by manually converting all sym links to their resolved paths. I can't think of any packages right now where defining prefix to a sym link breaks in this way.

let bindir_default = PathBuf::from("bin"); let libdir_default = PathBuf::from("lib"); let mandir_default = datadir_default.join("man"); <del> let prefix = build.config.prefix.as_ref().unwrap_or(&prefix_default); </del> <ins> let prefix = build.config.prefix.as_ref().map_or(prefix_default, |p| { fs::canonicalize(p).expect(&format!("could not canonicalize {}", p.display())) }); </ins> let sysconfdir = build.config.sysconfdir.as_ref().unwrap_or(&sysconfdir_default); let datadir = build.config.datadir.as_ref().unwrap_or(&datadir_default); let docdir = build.config.docdir.as_ref().unwrap_or(&docdir_default);


Question:
Here's an example:
I'm going to vote for this to be a 0.4 blocker since it's breaking cargos like . Cargo is violating an assumption in the parser that there's only one parser made per task. calls , which caches an interner in TLS on the first call, or assert if an interner has already been created. Unfortunately cargo creates a new parser session per crate, which triggers the assertion. I think this won't be too hard to work around. We could just get rid of the assertion, and share the interner across all parsers in the same thread. I'll prep a patch for this. I'm not sure if this will violate other assumptions in the compiler though. The other option would be to hack up cargo to run in a new thread. This will require some jury rigging, but it'll keep us from having to tweak the parser this close to release.
-- is this bug fixed now that your interner cache fix is merged?
yep, closing.

) fn mk_ident_interner() -> @ident_interner { <del> /* the indices here must correspond to the numbers in special_idents */ let init_vec = ~[@~"_", @~"anon", @~"drop", @~"", @~"unary", @~"!", @~"[]", @~"unary-", @~"__extensions__", @~"self", @~"item", @~"block", @~"stmt", @~"pat", @~"expr", @~"ty", @~"ident", @~"path", @~"tt", @~"matchers", @~"str", @~"TyVisitor", @~"arg", @~"descrim", @~"__rust_abi", @~"__rust_stack_shim", @~"TyDesc", @~"dtor", @~"main", @~"<opaque>", @~"blk", @~"static", @~"intrinsic", @~"__foreign_mod__"]; let rv = @ident_interner { interner: interner::mk_prefill::<@~str>(init_vec) }; /* having multiple interners will just confuse the serializer */ </del> unsafe { <del> assert task::local_data::local_data_get(interner_key!()).is_none() }; unsafe { task::local_data::local_data_set(interner_key!(), @rv) }; rv </del> <ins> match task::local_data::local_data_get(interner_key!()) { Some(interner) => *interner, None => { // the indices here must correspond to the numbers in // special_idents. let init_vec = ~[ @~"_", @~"anon", @~"drop", @~"", @~"unary", @~"!", @~"[]", @~"unary-", @~"__extensions__", @~"self", @~"item", @~"block", @~"stmt", @~"pat", @~"expr", @~"ty", @~"ident", @~"path", @~"tt", @~"matchers", @~"str", @~"TyVisitor", @~"arg", @~"descrim", @~"__rust_abi", @~"__rust_stack_shim", @~"TyDesc", @~"dtor", @~"main", @~"<opaque>", @~"blk", @~"static", @~"intrinsic", @~"__foreign_mod__" ]; let rv = @ident_interner { interner: interner::mk_prefill(init_vec) }; task::local_data::local_data_set(interner_key!(), @rv); rv } } } </ins> } /* for when we don't care about the contents; doesn't interact with TLD or


Question:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

pub llvm_version_check: bool, pub llvm_static_stdcpp: bool, pub llvm_link_shared: bool, <ins> pub llvm_targets: Option<String>, </ins> // rust codegen options pub rust_optimize: bool,


Question:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

release_debuginfo: Option<bool>, version_check: Option<bool>, static_libstdcpp: Option<bool>, <ins> targets: Option<String>, </ins> } #[derive(RustcDecodable)]


Question:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

set(&mut config.llvm_release_debuginfo, llvm.release_debuginfo); set(&mut config.llvm_version_check, llvm.version_check); set(&mut config.llvm_static_stdcpp, llvm.static_libstdcpp); <ins> config.llvm_targets = llvm.targets.clone(); </ins> } if let Some(ref rust) = toml.rust {


Question:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

# example. #ninja = false <ins> # LLVM targets to build support for. # Note: this is NOT related to Rust compilation targets. However, as Rust is # dependent on LLVM for code generation, turning targets off here WILL lead to # the resulting rustc being unable to compile for the disabled architectures. # Also worth pointing out is that, in case support for new targets are added to # LLVM, enabling them here doesn't mean Rust is automatically gaining said # support. You'll need to write a target specification at least, and most # likely, teach rustc about the C ABI of the target. Get in touch with the # Rust team and file an issue if you need assistance in porting! #targets = "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc" </ins> # ============================================================================= # General build configuration options # =============================================================================


Question:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

(true, true) => "RelWithDebInfo", }; <ins> // NOTE: remember to also update `config.toml.example` when changing the defaults! let llvm_targets = match build.config.llvm_targets { Some(ref s) => s, None => "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc", }; </ins> cfg.target(target) .host(&build.config.build) .out_dir(&dst) .profile(profile) .define("LLVM_ENABLE_ASSERTIONS", assertions) <del> .define("LLVM_TARGETS_TO_BUILD", "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc") </del> <ins> .define("LLVM_TARGETS_TO_BUILD", llvm_targets) </ins> .define("LLVM_INCLUDE_EXAMPLES", "OFF") .define("LLVM_INCLUDE_TESTS", "OFF") .define("LLVM_INCLUDE_DOCS", "OFF")


Question:
When building the following code: returns the following error message, which actually indicates the error, but also has a internal compiler error: My output:
Duplicate of , fixed in

} } <del> #[derive(Copy, Clone)] </del> <ins> #[derive(Copy, Clone, PartialEq)] </ins> enum PathScope { Global, Lexical,


Question:
When building the following code: returns the following error message, which actually indicates the error, but also has a internal compiler error: My output:
Duplicate of , fixed in

// // Such behavior is required for backward compatibility. // The same fallback is used when `a` resolves to nothing. <del> _ if self.primitive_type_table.primitive_types.contains_key(&path[0].name) => { </del> <ins> PathResult::Module(..) | PathResult::Failed(..) if scope == PathScope::Lexical && (ns == TypeNS || path.len() > 1) && self.primitive_type_table.primitive_types.contains_key(&path[0].name) => { </ins> PathResolution { base_def: Def::PrimTy(self.primitive_type_table.primitive_types[&path[0].name]), depth: segments.len() - 1,


Question:
When building the following code: returns the following error message, which actually indicates the error, but also has a internal compiler error: My output:
Duplicate of , fixed in

<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { // Make sure primitive type fallback doesn't work in value namespace std::mem::size_of(u16); //~^ ERROR unresolved name `u16` //~| ERROR this function takes 0 parameters but 1 parameter was supplied // Make sure primitive type fallback doesn't work with global paths let _: ::u8; //~^ ERROR type name `u8` is undefined or not in scope } </ins>


Question:
in a file's directory to indicate that the file has unsaved changes. When for features, the rustc development tool will fail if such a lockfile exists in the source tree, with (this part being the actual bug, being that a dirty tree should fail ) a message that doesn't make it clear what happened: (The novice compiler developer wonders: what file?) I think this is likely too obscure to be worth doing anything about, but somehow managed to fall slightly over my subjective threshold of "worth filing an Issue for"; sorry if I'm miscalibrated in this matter.
It looks like the has a two parameter case for reporting path errors, which means it could be fixed by just using
Yes, that's a bit better; thanks! :sparkling_heart: (trivial PR to follow)

} contents.truncate(0); <del> t!(t!(File::open(file)).read_to_string(&mut contents)); </del> <ins> t!(t!(File::open(&file), &file).read_to_string(&mut contents)); </ins> for (i, line) in contents.lines().enumerate() { let mut err = |msg: &str| {


Question:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

pub const EXCEPTION_MAXIMUM_PARAMETERS: usize = 15; pub const PIPE_ACCESS_INBOUND: DWORD = 0x00000001; <ins> pub const PIPE_ACCESS_OUTBOUND: DWORD = 0x00000002; </ins> pub const FILE_FLAG_FIRST_PIPE_INSTANCE: DWORD = 0x00080000; pub const FILE_FLAG_OVERLAPPED: DWORD = 0x40000000; pub const PIPE_WAIT: DWORD = 0x00000000;


Question:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

inner: Handle, } <del> pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> { </del> <ins> pub struct Pipes { pub ours: AnonPipe, pub theirs: AnonPipe, } /// Although this looks similar to `anon_pipe` in the Unix module it's actually /// subtly different. Here we'll return two pipes in the `Pipes` return value, /// but one is intended for "us" where as the other is intended for "someone /// else". /// /// Currently the only use case for this function is pipes for stdio on /// processes in the standard library, so "ours" is the one that'll stay in our /// process whereas "theirs" will be inherited to a child. /// /// The ours/theirs pipes are *not* specifically readable or writable. Each /// one only supports a read or a write, but which is which depends on the /// boolean flag given. If `ours_readable` is true then `ours` is readable where /// `theirs` is writable. Conversely if `ours_readable` is false then `ours` is /// writable where `theirs` is readable. /// /// Also note that the `ours` pipe is always a handle opened up in overlapped /// mode. This means that technically speaking it should only ever be used /// with `OVERLAPPED` instances, but also works out ok if it's only ever used /// once at a time (which we do indeed guarantee). pub fn anon_pipe(ours_readable: bool) -> io::Result<Pipes> { </ins> // Note that we specifically do *not* use `CreatePipe` here because // unfortunately the anonymous pipes returned do not support overlapped <del> // operations. // // Instead, we create a "hopefully unique" name and create a named pipe // which has overlapped operations enabled. </del> <ins> // operations. Instead, we create a "hopefully unique" name and create a // named pipe which has overlapped operations enabled. </ins> // <del> // Once we do this, we connect do it as usual via `CreateFileW`, and then we // return those reader/writer halves. </del> <ins> // Once we do this, we connect do it as usual via `CreateFileW`, and then // we return those reader/writer halves. Note that the `ours` pipe return // value is always the named pipe, whereas `theirs` is just the normal file. // This should hopefully shield us from child processes which assume their // stdout is a named pipe, which would indeed be odd! </ins> unsafe { <del> let reader; </del> <ins> let ours; </ins> let mut name; let mut tries = 0; let mut reject_remote_clients_flag = c::PIPE_REJECT_REMOTE_CLIENTS;


Question:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

.encode_wide() .chain(Some(0)) .collect::<Vec<_>>(); <ins> let mut flags = c::FILE_FLAG_FIRST_PIPE_INSTANCE | c::FILE_FLAG_OVERLAPPED; if ours_readable { flags |= c::PIPE_ACCESS_INBOUND; } else { flags |= c::PIPE_ACCESS_OUTBOUND; } </ins> let handle = c::CreateNamedPipeW(wide_name.as_ptr(), <del> c::PIPE_ACCESS_INBOUND | c::FILE_FLAG_FIRST_PIPE_INSTANCE | c::FILE_FLAG_OVERLAPPED, </del> <ins> flags, </ins> c::PIPE_TYPE_BYTE | c::PIPE_READMODE_BYTE | c::PIPE_WAIT |


Question:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

} return Err(err) } <del> reader = Handle::new(handle); </del> <ins> ours = Handle::new(handle); </ins> break } <del> // Connect to the named pipe we just created in write-only mode (also // overlapped for async I/O below). </del> <ins> // Connect to the named pipe we just created. This handle is going to be // returned in `theirs`, so if `ours` is readable we want this to be // writable, otherwise if `ours` is writable we want this to be // readable. // // Additionally we don't enable overlapped mode on this because most // client processes aren't enabled to work with that. </ins> let mut opts = OpenOptions::new(); <del> opts.write(true); opts.read(false); </del> <ins> opts.write(ours_readable); opts.read(!ours_readable); </ins> opts.share_mode(0); <del> opts.attributes(c::FILE_FLAG_OVERLAPPED); let writer = File::open(Path::new(&name), &opts)?; let writer = AnonPipe { inner: writer.into_handle() }; </del> <ins> let theirs = File::open(Path::new(&name), &opts)?; let theirs = AnonPipe { inner: theirs.into_handle() }; </ins> <del> Ok((AnonPipe { inner: reader }, AnonPipe { inner: writer.into_handle() })) </del> <ins> Ok(Pipes { ours: AnonPipe { inner: ours }, theirs: AnonPipe { inner: theirs.into_handle() }, }) </ins> } }


Question:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

} Stdio::MakePipe => { <del> let (reader, writer) = pipe::anon_pipe()?; let (ours, theirs) = if stdio_id == c::STD_INPUT_HANDLE { (writer, reader) } else { (reader, writer) }; *pipe = Some(ours); </del> <ins> let ours_readable = stdio_id != c::STD_INPUT_HANDLE; let pipes = pipe::anon_pipe(ours_readable)?; *pipe = Some(pipes.ours); </ins> cvt(unsafe { <del> c::SetHandleInformation(theirs.handle().raw(), </del> <ins> c::SetHandleInformation(pipes.theirs.handle().raw(), </ins> c::HANDLE_FLAG_INHERIT, c::HANDLE_FLAG_INHERIT) })?; <del> Ok(theirs.into_handle()) </del> <ins> Ok(pipes.theirs.into_handle()) </ins> } Stdio::Handle(ref handle) => {