Question:
EDIT(camelid): This issue is now being used to track a different, but related, bug. The discussion starting is current. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --- Clone . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this is probably related to somehow. I don't plan to investigate any of the proximate issues until the underlying problem is fixed. Feel free to take a look yourself if this is blocking your work, but it won't be easy.
Oh, I guess this could also be a missed case from That should be easier to fix.
If you can come up with an MCVE it would be easier to tell which of the two issues it is.
Not exactly an MCVE, but I think I'm able to reproduce this with only a handful of files The line does change slightly though: (Same rustc version output as above). Hope this helps :). Best, Mautamu
I think the issue is that the crate is first used in a dependency, so it isn't loaded in Maybe a fix is to recursively traverse the docs of re-exports? That sounds kind of expensive, but the only other option (besides fixing ) is to revert and re-open
An easy workaround is to link to somewhere in the crate re-exporting the docs, even something like this would work:
Hmm, this setup didn't reproduce the issue, not sure why:
Maybe the proc macro is related somehow?
Regression in searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThat's , good guess,
This regression now slipped into beta 1.53.0.
came up with a slightly smaller reproduction, the proc macro wasn't related:
We've also run into this recently with a rather trivial crate
This is likely to hit stable, as no beta-accepted patch appears available at this time.
Is there an easy way to help bisect to figure out which PR to revert, or otherwise help along this issue? It’d be somewhat sad for our five-method create to not have docs even on stable.
you can use the workaround I mentioned at the top: is the PR to revert; I'm not wholly opposed to doing so but it means reintroducing other regressions. See .
This now occurs on stable and should likely be tagged , I assume.
A note to others who stumble upon this, the workaround in works great; to figure out which crate(s) you need to list, run: Look for the last log message before the panic — in my case, that was: Adding fixed the problem.
should give you a lot less logging and still show the right crate.
Further minimized from and turned into a rustdoc test form:
thanks for the reduction, that helped a lot. The problem is that rustdoc is considering each line on its own, when it should be considering the whole documentation for the item at once: When there's a reference link, rustdoc will see the link text instead of the link target: The fix is to use in instead of visiting each attribute one by one.
I experienced this same issue today on 1.56 stable despite the fix. The log followed the same pattern as above when run with . Removing this dependency fixed the problem:
can you post a link to the code that caused the ICE?
cc
reports the same issue in an open source codebase:
Also seeing this in another project in 1.56 stable. Would put together a reproducer but there already is one.
If you could minimize the crash that would be helpful, the one at the top was already fixed by
I've reduced it to Still seems a bit large but having trouble getting it any smaller. This reproducer involves I suspect that is the root cause in this case, not sure if that tracks with the other reports.
how can I build that package? running gives me even though I have gcc installed.
The dependency is macOS only. GitHub runners can do it. There is probably a way to shrink the dependency enough to build on some other platform, can look into it a bit more
Updated to ICE on windows, which I suspect is enough for linux as well. May require or
Hmm, so something strange is going on here - I example a little more, down to four local crates: If has the contents of , then the issue reproduces correctly, but if it's anything smaller, then documents fine. At first I suspected the crate hash was different or something, but cargo is passing different hashes even when and are identical, so that's not it.
FWIW you can work around the ICE with this diff:
Really interesting workaround! Those ought to be the same due to , maybe there’s some interaction there?
see
MCVE:

} } <del> impl ast::visit::Visitor<'_> for IntraLinkCrateLoader { </del> <ins> impl visit::Visitor<'_> for IntraLinkCrateLoader { fn visit_foreign_item(&mut self, item: &ast::ForeignItem) { self.load_links_in_attrs(&item.attrs, item.span); visit::walk_foreign_item(self, item) } </ins> fn visit_item(&mut self, item: &ast::Item) { use rustc_ast_lowering::ResolverAstLowering;


Question:
EDIT(camelid): This issue is now being used to track a different, but related, bug. The discussion starting is current. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --- Clone . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this is probably related to somehow. I don't plan to investigate any of the proximate issues until the underlying problem is fixed. Feel free to take a look yourself if this is blocking your work, but it won't be easy.
Oh, I guess this could also be a missed case from That should be easier to fix.
If you can come up with an MCVE it would be easier to tell which of the two issues it is.
Not exactly an MCVE, but I think I'm able to reproduce this with only a handful of files The line does change slightly though: (Same rustc version output as above). Hope this helps :). Best, Mautamu
I think the issue is that the crate is first used in a dependency, so it isn't loaded in Maybe a fix is to recursively traverse the docs of re-exports? That sounds kind of expensive, but the only other option (besides fixing ) is to revert and re-open
An easy workaround is to link to somewhere in the crate re-exporting the docs, even something like this would work:
Hmm, this setup didn't reproduce the issue, not sure why:
Maybe the proc macro is related somehow?
Regression in searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThat's , good guess,
This regression now slipped into beta 1.53.0.
came up with a slightly smaller reproduction, the proc macro wasn't related:
We've also run into this recently with a rather trivial crate
This is likely to hit stable, as no beta-accepted patch appears available at this time.
Is there an easy way to help bisect to figure out which PR to revert, or otherwise help along this issue? It’d be somewhat sad for our five-method create to not have docs even on stable.
you can use the workaround I mentioned at the top: is the PR to revert; I'm not wholly opposed to doing so but it means reintroducing other regressions. See .
This now occurs on stable and should likely be tagged , I assume.
A note to others who stumble upon this, the workaround in works great; to figure out which crate(s) you need to list, run: Look for the last log message before the panic — in my case, that was: Adding fixed the problem.
should give you a lot less logging and still show the right crate.
Further minimized from and turned into a rustdoc test form:
thanks for the reduction, that helped a lot. The problem is that rustdoc is considering each line on its own, when it should be considering the whole documentation for the item at once: When there's a reference link, rustdoc will see the link text instead of the link target: The fix is to use in instead of visiting each attribute one by one.
I experienced this same issue today on 1.56 stable despite the fix. The log followed the same pattern as above when run with . Removing this dependency fixed the problem:
can you post a link to the code that caused the ICE?
cc
reports the same issue in an open source codebase:
Also seeing this in another project in 1.56 stable. Would put together a reproducer but there already is one.
If you could minimize the crash that would be helpful, the one at the top was already fixed by
I've reduced it to Still seems a bit large but having trouble getting it any smaller. This reproducer involves I suspect that is the root cause in this case, not sure if that tracks with the other reports.
how can I build that package? running gives me even though I have gcc installed.
The dependency is macOS only. GitHub runners can do it. There is probably a way to shrink the dependency enough to build on some other platform, can look into it a bit more
Updated to ICE on windows, which I suspect is enough for linux as well. May require or
Hmm, so something strange is going on here - I example a little more, down to four local crates: If has the contents of , then the issue reproduces correctly, but if it's anything smaller, then documents fine. At first I suspected the crate hash was different or something, but cargo is passing different hashes even when and are identical, so that's not it.
FWIW you can work around the ICE with this diff:
Really interesting workaround! Those ought to be the same due to , maybe there’s some interaction there?
see
MCVE:

let old_mod = mem::replace(&mut self.current_mod, new_mod); self.load_links_in_attrs(&item.attrs, item.span); <del> ast::visit::walk_item(self, item); </del> <ins> visit::walk_item(self, item); </ins> self.current_mod = old_mod; } else { self.load_links_in_attrs(&item.attrs, item.span); <del> ast::visit::walk_item(self, item); </del> <ins> visit::walk_item(self, item); </ins> } } <ins> // NOTE: if doc-comments are ever allowed on function parameters, this will have to implement `visit_param` too. fn visit_assoc_item(&mut self, item: &ast::AssocItem, ctxt: visit::AssocCtxt) { self.load_links_in_attrs(&item.attrs, item.span); visit::walk_assoc_item(self, item, ctxt) } fn visit_field_def(&mut self, field: &ast::FieldDef) { self.load_links_in_attrs(&field.attrs, field.span); visit::walk_field_def(self, field) } fn visit_variant(&mut self, v: &ast::Variant) { self.load_links_in_attrs(&v.attrs, v.span); visit::walk_variant(self, v) } </ins> }


Question:
EDIT(camelid): This issue is now being used to track a different, but related, bug. The discussion starting is current. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --- Clone . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this is probably related to somehow. I don't plan to investigate any of the proximate issues until the underlying problem is fixed. Feel free to take a look yourself if this is blocking your work, but it won't be easy.
Oh, I guess this could also be a missed case from That should be easier to fix.
If you can come up with an MCVE it would be easier to tell which of the two issues it is.
Not exactly an MCVE, but I think I'm able to reproduce this with only a handful of files The line does change slightly though: (Same rustc version output as above). Hope this helps :). Best, Mautamu
I think the issue is that the crate is first used in a dependency, so it isn't loaded in Maybe a fix is to recursively traverse the docs of re-exports? That sounds kind of expensive, but the only other option (besides fixing ) is to revert and re-open
An easy workaround is to link to somewhere in the crate re-exporting the docs, even something like this would work:
Hmm, this setup didn't reproduce the issue, not sure why:
Maybe the proc macro is related somehow?
Regression in searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThat's , good guess,
This regression now slipped into beta 1.53.0.
came up with a slightly smaller reproduction, the proc macro wasn't related:
We've also run into this recently with a rather trivial crate
This is likely to hit stable, as no beta-accepted patch appears available at this time.
Is there an easy way to help bisect to figure out which PR to revert, or otherwise help along this issue? It’d be somewhat sad for our five-method create to not have docs even on stable.
you can use the workaround I mentioned at the top: is the PR to revert; I'm not wholly opposed to doing so but it means reintroducing other regressions. See .
This now occurs on stable and should likely be tagged , I assume.
A note to others who stumble upon this, the workaround in works great; to figure out which crate(s) you need to list, run: Look for the last log message before the panic — in my case, that was: Adding fixed the problem.
should give you a lot less logging and still show the right crate.
Further minimized from and turned into a rustdoc test form:
thanks for the reduction, that helped a lot. The problem is that rustdoc is considering each line on its own, when it should be considering the whole documentation for the item at once: When there's a reference link, rustdoc will see the link text instead of the link target: The fix is to use in instead of visiting each attribute one by one.
I experienced this same issue today on 1.56 stable despite the fix. The log followed the same pattern as above when run with . Removing this dependency fixed the problem:
can you post a link to the code that caused the ICE?
cc
reports the same issue in an open source codebase:
Also seeing this in another project in 1.56 stable. Would put together a reproducer but there already is one.
If you could minimize the crash that would be helpful, the one at the top was already fixed by
I've reduced it to Still seems a bit large but having trouble getting it any smaller. This reproducer involves I suspect that is the root cause in this case, not sure if that tracks with the other reports.
how can I build that package? running gives me even though I have gcc installed.
The dependency is macOS only. GitHub runners can do it. There is probably a way to shrink the dependency enough to build on some other platform, can look into it a bit more
Updated to ICE on windows, which I suspect is enough for linux as well. May require or
Hmm, so something strange is going on here - I example a little more, down to four local crates: If has the contents of , then the issue reproduces correctly, but if it's anything smaller, then documents fine. At first I suspected the crate hash was different or something, but cargo is passing different hashes even when and are identical, so that's not it.
FWIW you can work around the ICE with this diff:
Really interesting workaround! Those ought to be the same due to , maybe there’s some interaction there?
see
MCVE:

<ins> // check-pass // aux-crate:dep1=dep1.rs // aux-crate:dep2=dep2.rs // aux-crate:dep3=dep3.rs // aux-crate:dep4=dep4.rs #![deny(rustdoc::broken_intra_doc_links)] pub trait Trait { /// [dep1] type Item; } pub struct S { /// [dep2] pub x: usize, } extern "C" { /// [dep3] pub fn printf(); } pub enum E { /// [dep4] A } </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

pub const TRUE: BOOL = 1; pub const FALSE: BOOL = 0; <ins> pub const CSTR_LESS_THAN: c_int = 1; pub const CSTR_EQUAL: c_int = 2; pub const CSTR_GREATER_THAN: c_int = 3; </ins> pub const FILE_ATTRIBUTE_READONLY: DWORD = 0x1; pub const FILE_ATTRIBUTE_DIRECTORY: DWORD = 0x10; pub const FILE_ATTRIBUTE_REPARSE_POINT: DWORD = 0x400;


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

pub fn ReleaseSRWLockShared(SRWLock: PSRWLOCK); pub fn TryAcquireSRWLockExclusive(SRWLock: PSRWLOCK) -> BOOLEAN; pub fn TryAcquireSRWLockShared(SRWLock: PSRWLOCK) -> BOOLEAN; <ins> pub fn CompareStringOrdinal( lpString1: LPCWSTR, cchCount1: c_int, lpString2: LPCWSTR, cchCount2: c_int, bIgnoreCase: BOOL, ) -> c_int; </ins> } // Functions that aren't available on every version of Windows that we support,


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

mod tests; use crate::borrow::Borrow; <ins> use crate::cmp; </ins> use crate::collections::BTreeMap; use crate::convert::{TryFrom, TryInto}; use crate::env;


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

// Command //////////////////////////////////////////////////////////////////////////////// <del> #[derive(Clone, Debug, Eq, PartialEq, Ord, PartialOrd)] </del> <ins> #[derive(Clone, Debug, Eq)] </ins> #[doc(hidden)] <del> pub struct EnvKey(OsString); </del> <ins> pub struct EnvKey { os_string: OsString, // This stores a UTF-16 encoded string to workaround the mismatch between // Rust's OsString (WTF-8) and the Windows API string type (UTF-16). // Normally converting on every API call is acceptable but here // `c::CompareStringOrdinal` will be called for every use of `==`. utf16: Vec<u16>, } // Comparing Windows environment variable keys[1] are behaviourally the // composition of two operations[2]: // // 1. Case-fold both strings. This is done using a language-independent // uppercase mapping that's unique to Windows (albeit based on data from an // older Unicode spec). It only operates on individual UTF-16 code units so // surrogates are left unchanged. This uppercase mapping can potentially change // between Windows versions. // // 2. Perform an ordinal comparison of the strings. A comparison using ordinal // is just a comparison based on the numerical value of each UTF-16 code unit[3]. // // Because the case-folding mapping is unique to Windows and not guaranteed to // be stable, we ask the OS to compare the strings for us. This is done by // calling `CompareStringOrdinal`[4] with `bIgnoreCase` set to `TRUE`. // // [1] https://docs.microsoft.com/en-us/dotnet/standard/base-types/best-practices-strings#choosing-a-stringcomparison-member-for-your-method-call // [2] https://docs.microsoft.com/en-us/dotnet/standard/base-types/best-practices-strings#stringtoupper-and-stringtolower // [3] https://docs.microsoft.com/en-us/dotnet/api/system.stringcomparison?view=net-5.0#System_StringComparison_Ordinal // [4] https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-comparestringordinal impl Ord for EnvKey { fn cmp(&self, other: &Self) -> cmp::Ordering { unsafe { let result = c::CompareStringOrdinal( self.utf16.as_ptr(), self.utf16.len() as _, other.utf16.as_ptr(), other.utf16.len() as _, c::TRUE, ); match result { c::CSTR_LESS_THAN => cmp::Ordering::Less, c::CSTR_EQUAL => cmp::Ordering::Equal, c::CSTR_GREATER_THAN => cmp::Ordering::Greater, // `CompareStringOrdinal` should never fail so long as the parameters are correct. _ => panic!("comparing environment keys failed: {}", Error::last_os_error()), } } } } impl PartialOrd for EnvKey { fn partial_cmp(&self, other: &Self) -> Option<cmp::Ordering> { Some(self.cmp(other)) } } impl PartialEq for EnvKey { fn eq(&self, other: &Self) -> bool { if self.utf16.len() != other.utf16.len() { false } else { self.cmp(other) == cmp::Ordering::Equal } } } // Environment variable keys should preserve their original case even though // they are compared using a caseless string mapping. </ins> impl From<OsString> for EnvKey { <del> fn from(mut k: OsString) -> Self { k.make_ascii_uppercase(); EnvKey(k) </del> <ins> fn from(k: OsString) -> Self { EnvKey { utf16: k.encode_wide().collect(), os_string: k } </ins> } } impl From<EnvKey> for OsString { fn from(k: EnvKey) -> Self { <del> k.0 </del> <ins> k.os_string </ins> } } impl Borrow<OsStr> for EnvKey { fn borrow(&self) -> &OsStr { <del> &self.0 </del> <ins> &self.os_string </ins> } } impl AsRef<OsStr> for EnvKey { fn as_ref(&self) -> &OsStr { <del> &self.0 </del> <ins> &self.os_string </ins> } }


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

let mut blk = Vec::new(); for (k, v) in env { <del> blk.extend(ensure_no_nuls(k.0)?.encode_wide()); </del> <ins> ensure_no_nuls(k.os_string)?; blk.extend(k.utf16); </ins> blk.push('=' as u16); blk.extend(ensure_no_nuls(v)?.encode_wide()); blk.push(0);


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

use super::make_command_line; <ins> use crate::env; </ins> use crate::ffi::{OsStr, OsString}; <ins> use crate::process::Command; </ins> #[test] fn test_make_command_line() {


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.

""u{03c0}u{042f}u{97f3}u{00e6}u{221e}"" ); } <ins> // On Windows, environment args are case preserving but comparisons are case-insensitive. // See: #85242 #[test] fn windows_env_unicode_case() { let test_cases = [ ("ä", "Ä"), ("ß", "SS"), ("Ä", "Ö"), ("Ä", "Ö"), ("I", "İ"), ("I", "i"), ("I", "ı"), ("i", "I"), ("i", "İ"), ("i", "ı"), ("İ", "I"), ("İ", "i"), ("İ", "ı"), ("ı", "I"), ("ı", "i"), ("ı", "İ"), ("ä", "Ä"), ("ß", "SS"), ("Ä", "Ö"), ("Ä", "Ö"), ("I", "İ"), ("I", "i"), ("I", "ı"), ("i", "I"), ("i", "İ"), ("i", "ı"), ("İ", "I"), ("İ", "i"), ("İ", "ı"), ("ı", "I"), ("ı", "i"), ("ı", "İ"), ]; // Test that `cmd.env` matches `env::set_var` when setting two strings that // may (or may not) be case-folded when compared. for (a, b) in test_cases.iter() { let mut cmd = Command::new("cmd"); cmd.env(a, "1"); cmd.env(b, "2"); env::set_var(a, "1"); env::set_var(b, "2"); for (key, value) in cmd.get_envs() { assert_eq!( env::var(key).ok(), value.map(|s| s.to_string_lossy().into_owned()), "command environment mismatch: {} {}", a, b ); } } } </ins>


Question:
Hello, Linking crate on fails when using . The link succeeds when using I expected to see this happen: linking successful. Instead, this happened: :
I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.) So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug... Thanks and sorry for the churn...
Even worth, I suspect you deleted your previous comment :yum:. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed. But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven :smile:
I see is about to be stabilized: Will this issue be solved before stabilization?
I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this? Also note the theory and workaround suggested in I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment). Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too. Thanks! Cc:
Yep, I'll take a look this week!
I hit this with the crate today as well, so any project with in its tree ( for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...
- Did you have any opportunity to look into this?
I'm still looking into this but I have managed to construct a minimal (I believe) repro: Which, with the appropriate flags, will then trigger the link error: There's quite a lot of dead code in the "minimal" repro but removing any of it or even moving it around causes the error to go away. We need basically this exact structure to get the codegen units to be placed into the state which triggers this bug.
Thank you! Having a reproducible example like this is still very helpful. It's not a stretch to assume the trigger relates to the CGU-specific logic in My educated guess (still a guess though) is that we're trying to for the same unused from multiple CGUs. I will try your example on Linux as well, just to be certain this reproducible case really is Windows specific. If it is the CGU logic, and is Windows-specific, the question I have is, what's different between Windows and other platforms like Linux? Some half-baked theories: Codegen on Linux is not actually using multiple codegen units? (Or not as commonly/extensively as on Windows?) I assume this is not the case. Some subtle difference in the parallelism between Windows and Linux is making this situation more likely on Windows? I can't picture how it would be that deterministic on Windows. Differences between the linkers and/or linker parameters, and how they handle duplicate symbols. If so, is this a "bug" in that we can "fix" to make linking on Windows more like linking on the other platforms?
It might also be worth logging the s in that call on line 374, maybe along with identifying the CGU, to confirm that more than one CGU is trying to define the same (unless you already know this to be the case).
- What is the filename for the last chunk of rust code? It doesn't appear to be referenced from any of the other files, unless I'm missing something. I wonder why it gets pulled into the compilation?
Woops, sorry about that! I've updated the comment to include the file name. It's pulled in by the statement in . Codegen on Linux does use multiple cgus (especially when is passed). At least from my tests, is the minimum number of CGUs required to trigger this. I haven't had any issue reproducing with this source (ie, it's not intermittent when the source code is not changed). So it doesn't feel like a parallelism/determinism issue to me. This seems like the most likely issue to me. I'm digging into the symbol table and LLVM IR ...
FYI, I just compiled this on my Linux machine, using , and I a debug message. It does indeed appear to define the same from different CGUs, but it links successfully. This log is printed twice, with two different cgu names:
(In case you'd like to try the same, I this line right before the call to :
Here's another (surprising? to me anyway) clue: I a debug log here: And two CGU's ( shown below and a different CGU) printed identical results: Doesn't this mean that the two CGUs are redundantly generating code for the same 5 functions (6 including the undefined function coverage is adding)? Is there something about the symbols generated for the "used" functions shown here that makes them unique within their CGU, so Windows is not getting linker errors on the used functions as well? Wishful thinking, maybe this identifies an opportunity to improve compiler performance, but more likely I just misunderstood the relationship between the CGUs and the results from the call to .
Ok, that was super helpful and pointed me in the direction of the actual minimal repro. Thanks Since is marked , it's included in the CGU for and the CGU for . Therefore, both CGUs think they should be responsible for generating the unused function and there are two copies of it generated. While the functions are generated as weak symbols, the MSVC linker seems to treat weak symbols differently than unix-y linkers do. I'm a bit curious why we use instead of for these functions? Using seems to produce the correct results (at least in this simple test): Changing to use those attributes instead seems like a quick, easy fix to resolve this for now. A better solution might be to reserve one CGU and put all of the dead code in that CGU which would sidestep the entire issue by ensuring there is only one CGU with these functions in it.
Let's try it! Are you planning to submit the PR or do you want me to. I think this is harder than it might seem on the surface. If I recall correctly, this was something I looked into, but the information required was not where I needed it, after CGU partitioning. Someone may know a way to do it, but I just want to caution that it might not be that trivial.
Let's see if CI passes
Historical context: See ... My depth of understanding of all of the different linkage options is still more shallow than I'd like. I read the LLVM documentation descriptions several times, but the number of combinations, and their effects, are still hard for me to understand. Some choices I had to make were an "educated guess" on my part. As you can see, MOST of the time, the current linkage works, but if your suggested changes resolve these issues without breaking anything else, that's fantastic.
Ah, thanks! I won't claim my understanding of the linkage options is complete either, but I think will cause the dead code functions' symbols to be made private to the CGU they're declared in and prevent any name collisions by renaming if necessary.

), ); <del> llvm::set_linkage(llfn, llvm::Linkage::WeakAnyLinkage); llvm::set_visibility(llfn, llvm::Visibility::Hidden); </del> <ins> llvm::set_linkage(llfn, llvm::Linkage::PrivateLinkage); llvm::set_visibility(llfn, llvm::Visibility::Default); </ins> assert!(cx.instances.borrow_mut().insert(instance, llfn).is_none());


Question:
Hello, Linking crate on fails when using . The link succeeds when using I expected to see this happen: linking successful. Instead, this happened: :
I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.) So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug... Thanks and sorry for the churn...
Even worth, I suspect you deleted your previous comment :yum:. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed. But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven :smile:
I see is about to be stabilized: Will this issue be solved before stabilization?
I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this? Also note the theory and workaround suggested in I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment). Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too. Thanks! Cc:
Yep, I'll take a look this week!
I hit this with the crate today as well, so any project with in its tree ( for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...
- Did you have any opportunity to look into this?
I'm still looking into this but I have managed to construct a minimal (I believe) repro: Which, with the appropriate flags, will then trigger the link error: There's quite a lot of dead code in the "minimal" repro but removing any of it or even moving it around causes the error to go away. We need basically this exact structure to get the codegen units to be placed into the state which triggers this bug.
Thank you! Having a reproducible example like this is still very helpful. It's not a stretch to assume the trigger relates to the CGU-specific logic in My educated guess (still a guess though) is that we're trying to for the same unused from multiple CGUs. I will try your example on Linux as well, just to be certain this reproducible case really is Windows specific. If it is the CGU logic, and is Windows-specific, the question I have is, what's different between Windows and other platforms like Linux? Some half-baked theories: Codegen on Linux is not actually using multiple codegen units? (Or not as commonly/extensively as on Windows?) I assume this is not the case. Some subtle difference in the parallelism between Windows and Linux is making this situation more likely on Windows? I can't picture how it would be that deterministic on Windows. Differences between the linkers and/or linker parameters, and how they handle duplicate symbols. If so, is this a "bug" in that we can "fix" to make linking on Windows more like linking on the other platforms?
It might also be worth logging the s in that call on line 374, maybe along with identifying the CGU, to confirm that more than one CGU is trying to define the same (unless you already know this to be the case).
- What is the filename for the last chunk of rust code? It doesn't appear to be referenced from any of the other files, unless I'm missing something. I wonder why it gets pulled into the compilation?
Woops, sorry about that! I've updated the comment to include the file name. It's pulled in by the statement in . Codegen on Linux does use multiple cgus (especially when is passed). At least from my tests, is the minimum number of CGUs required to trigger this. I haven't had any issue reproducing with this source (ie, it's not intermittent when the source code is not changed). So it doesn't feel like a parallelism/determinism issue to me. This seems like the most likely issue to me. I'm digging into the symbol table and LLVM IR ...
FYI, I just compiled this on my Linux machine, using , and I a debug message. It does indeed appear to define the same from different CGUs, but it links successfully. This log is printed twice, with two different cgu names:
(In case you'd like to try the same, I this line right before the call to :
Here's another (surprising? to me anyway) clue: I a debug log here: And two CGU's ( shown below and a different CGU) printed identical results: Doesn't this mean that the two CGUs are redundantly generating code for the same 5 functions (6 including the undefined function coverage is adding)? Is there something about the symbols generated for the "used" functions shown here that makes them unique within their CGU, so Windows is not getting linker errors on the used functions as well? Wishful thinking, maybe this identifies an opportunity to improve compiler performance, but more likely I just misunderstood the relationship between the CGUs and the results from the call to .
Ok, that was super helpful and pointed me in the direction of the actual minimal repro. Thanks Since is marked , it's included in the CGU for and the CGU for . Therefore, both CGUs think they should be responsible for generating the unused function and there are two copies of it generated. While the functions are generated as weak symbols, the MSVC linker seems to treat weak symbols differently than unix-y linkers do. I'm a bit curious why we use instead of for these functions? Using seems to produce the correct results (at least in this simple test): Changing to use those attributes instead seems like a quick, easy fix to resolve this for now. A better solution might be to reserve one CGU and put all of the dead code in that CGU which would sidestep the entire issue by ensuring there is only one CGU with these functions in it.
Let's try it! Are you planning to submit the PR or do you want me to. I think this is harder than it might seem on the surface. If I recall correctly, this was something I looked into, but the information required was not where I needed it, after CGU partitioning. Someone may know a way to do it, but I just want to caution that it might not be that trivial.
Let's see if CI passes
Historical context: See ... My depth of understanding of all of the different linkage options is still more shallow than I'd like. I read the LLVM documentation descriptions several times, but the number of combinations, and their effects, are still hard for me to understand. Some choices I had to make were an "educated guess" on my part. As you can see, MOST of the time, the current linkage works, but if your suggested changes resolve these issues without breaking anything else, that's fantastic.
Ah, thanks! I won't claim my understanding of the linkage options is complete either, but I think will cause the dead code functions' symbols to be made private to the CGU they're declared in and prevent any name collisions by renaming if necessary.

<ins> ../coverage/issue-85461.rs: 1|       |// Regression test for #85461: MSVC sometimes fail to link with dead code and #[inline(always)] 2|       | 3|       |extern crate inline_always_with_dead_code; 4|       | 5|       |use inline_always_with_dead_code::{bar, baz}; 6|       | 7|      1|fn main() { 8|      1|    bar::call_me(); 9|      1|    baz::call_me(); 10|      1|} ../coverage/lib/inline_always_with_dead_code.rs: 1|       |// compile-flags: -Zinstrument-coverage -Ccodegen-units=4 -Copt-level=0 2|       | 3|       |#![allow(dead_code)] 4|       | 5|       |mod foo { 6|       |    #[inline(always)] 7|      2|    pub fn called() { } 8|       | 9|      0|    fn uncalled() { } 10|       |} 11|       | 12|       |pub mod bar { 13|      1|    pub fn call_me() { 14|      1|        super::foo::called(); 15|      1|    } 16|       |} 17|       | 18|       |pub mod baz { 19|      1|    pub fn call_me() { 20|      1|        super::foo::called(); 21|      1|    } 22|       |} </ins>


Question:
Hello, Linking crate on fails when using . The link succeeds when using I expected to see this happen: linking successful. Instead, this happened: :
I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.) So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug... Thanks and sorry for the churn...
Even worth, I suspect you deleted your previous comment :yum:. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed. But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven :smile:
I see is about to be stabilized: Will this issue be solved before stabilization?
I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this? Also note the theory and workaround suggested in I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment). Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too. Thanks! Cc:
Yep, I'll take a look this week!
I hit this with the crate today as well, so any project with in its tree ( for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...
- Did you have any opportunity to look into this?
I'm still looking into this but I have managed to construct a minimal (I believe) repro: Which, with the appropriate flags, will then trigger the link error: There's quite a lot of dead code in the "minimal" repro but removing any of it or even moving it around causes the error to go away. We need basically this exact structure to get the codegen units to be placed into the state which triggers this bug.
Thank you! Having a reproducible example like this is still very helpful. It's not a stretch to assume the trigger relates to the CGU-specific logic in My educated guess (still a guess though) is that we're trying to for the same unused from multiple CGUs. I will try your example on Linux as well, just to be certain this reproducible case really is Windows specific. If it is the CGU logic, and is Windows-specific, the question I have is, what's different between Windows and other platforms like Linux? Some half-baked theories: Codegen on Linux is not actually using multiple codegen units? (Or not as commonly/extensively as on Windows?) I assume this is not the case. Some subtle difference in the parallelism between Windows and Linux is making this situation more likely on Windows? I can't picture how it would be that deterministic on Windows. Differences between the linkers and/or linker parameters, and how they handle duplicate symbols. If so, is this a "bug" in that we can "fix" to make linking on Windows more like linking on the other platforms?
It might also be worth logging the s in that call on line 374, maybe along with identifying the CGU, to confirm that more than one CGU is trying to define the same (unless you already know this to be the case).
- What is the filename for the last chunk of rust code? It doesn't appear to be referenced from any of the other files, unless I'm missing something. I wonder why it gets pulled into the compilation?
Woops, sorry about that! I've updated the comment to include the file name. It's pulled in by the statement in . Codegen on Linux does use multiple cgus (especially when is passed). At least from my tests, is the minimum number of CGUs required to trigger this. I haven't had any issue reproducing with this source (ie, it's not intermittent when the source code is not changed). So it doesn't feel like a parallelism/determinism issue to me. This seems like the most likely issue to me. I'm digging into the symbol table and LLVM IR ...
FYI, I just compiled this on my Linux machine, using , and I a debug message. It does indeed appear to define the same from different CGUs, but it links successfully. This log is printed twice, with two different cgu names:
(In case you'd like to try the same, I this line right before the call to :
Here's another (surprising? to me anyway) clue: I a debug log here: And two CGU's ( shown below and a different CGU) printed identical results: Doesn't this mean that the two CGUs are redundantly generating code for the same 5 functions (6 including the undefined function coverage is adding)? Is there something about the symbols generated for the "used" functions shown here that makes them unique within their CGU, so Windows is not getting linker errors on the used functions as well? Wishful thinking, maybe this identifies an opportunity to improve compiler performance, but more likely I just misunderstood the relationship between the CGUs and the results from the call to .
Ok, that was super helpful and pointed me in the direction of the actual minimal repro. Thanks Since is marked , it's included in the CGU for and the CGU for . Therefore, both CGUs think they should be responsible for generating the unused function and there are two copies of it generated. While the functions are generated as weak symbols, the MSVC linker seems to treat weak symbols differently than unix-y linkers do. I'm a bit curious why we use instead of for these functions? Using seems to produce the correct results (at least in this simple test): Changing to use those attributes instead seems like a quick, easy fix to resolve this for now. A better solution might be to reserve one CGU and put all of the dead code in that CGU which would sidestep the entire issue by ensuring there is only one CGU with these functions in it.
Let's try it! Are you planning to submit the PR or do you want me to. I think this is harder than it might seem on the surface. If I recall correctly, this was something I looked into, but the information required was not where I needed it, after CGU partitioning. Someone may know a way to do it, but I just want to caution that it might not be that trivial.
Let's see if CI passes
Historical context: See ... My depth of understanding of all of the different linkage options is still more shallow than I'd like. I read the LLVM documentation descriptions several times, but the number of combinations, and their effects, are still hard for me to understand. Some choices I had to make were an "educated guess" on my part. As you can see, MOST of the time, the current linkage works, but if your suggested changes resolve these issues without breaking anything else, that's fantastic.
Ah, thanks! I won't claim my understanding of the linkage options is complete either, but I think will cause the dead code functions' symbols to be made private to the CGU they're declared in and prevent any name collisions by renaming if necessary.

<ins> // Regression test for #85461: MSVC sometimes fail to link with dead code and #[inline(always)] extern crate inline_always_with_dead_code; use inline_always_with_dead_code::{bar, baz}; fn main() { bar::call_me(); baz::call_me(); } </ins>


Question:
Hello, Linking crate on fails when using . The link succeeds when using I expected to see this happen: linking successful. Instead, this happened: :
I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.) So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug... Thanks and sorry for the churn...
Even worth, I suspect you deleted your previous comment :yum:. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed. But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven :smile:
I see is about to be stabilized: Will this issue be solved before stabilization?
I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this? Also note the theory and workaround suggested in I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment). Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too. Thanks! Cc:
Yep, I'll take a look this week!
I hit this with the crate today as well, so any project with in its tree ( for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...
- Did you have any opportunity to look into this?
I'm still looking into this but I have managed to construct a minimal (I believe) repro: Which, with the appropriate flags, will then trigger the link error: There's quite a lot of dead code in the "minimal" repro but removing any of it or even moving it around causes the error to go away. We need basically this exact structure to get the codegen units to be placed into the state which triggers this bug.
Thank you! Having a reproducible example like this is still very helpful. It's not a stretch to assume the trigger relates to the CGU-specific logic in My educated guess (still a guess though) is that we're trying to for the same unused from multiple CGUs. I will try your example on Linux as well, just to be certain this reproducible case really is Windows specific. If it is the CGU logic, and is Windows-specific, the question I have is, what's different between Windows and other platforms like Linux? Some half-baked theories: Codegen on Linux is not actually using multiple codegen units? (Or not as commonly/extensively as on Windows?) I assume this is not the case. Some subtle difference in the parallelism between Windows and Linux is making this situation more likely on Windows? I can't picture how it would be that deterministic on Windows. Differences between the linkers and/or linker parameters, and how they handle duplicate symbols. If so, is this a "bug" in that we can "fix" to make linking on Windows more like linking on the other platforms?
It might also be worth logging the s in that call on line 374, maybe along with identifying the CGU, to confirm that more than one CGU is trying to define the same (unless you already know this to be the case).
- What is the filename for the last chunk of rust code? It doesn't appear to be referenced from any of the other files, unless I'm missing something. I wonder why it gets pulled into the compilation?
Woops, sorry about that! I've updated the comment to include the file name. It's pulled in by the statement in . Codegen on Linux does use multiple cgus (especially when is passed). At least from my tests, is the minimum number of CGUs required to trigger this. I haven't had any issue reproducing with this source (ie, it's not intermittent when the source code is not changed). So it doesn't feel like a parallelism/determinism issue to me. This seems like the most likely issue to me. I'm digging into the symbol table and LLVM IR ...
FYI, I just compiled this on my Linux machine, using , and I a debug message. It does indeed appear to define the same from different CGUs, but it links successfully. This log is printed twice, with two different cgu names:
(In case you'd like to try the same, I this line right before the call to :
Here's another (surprising? to me anyway) clue: I a debug log here: And two CGU's ( shown below and a different CGU) printed identical results: Doesn't this mean that the two CGUs are redundantly generating code for the same 5 functions (6 including the undefined function coverage is adding)? Is there something about the symbols generated for the "used" functions shown here that makes them unique within their CGU, so Windows is not getting linker errors on the used functions as well? Wishful thinking, maybe this identifies an opportunity to improve compiler performance, but more likely I just misunderstood the relationship between the CGUs and the results from the call to .
Ok, that was super helpful and pointed me in the direction of the actual minimal repro. Thanks Since is marked , it's included in the CGU for and the CGU for . Therefore, both CGUs think they should be responsible for generating the unused function and there are two copies of it generated. While the functions are generated as weak symbols, the MSVC linker seems to treat weak symbols differently than unix-y linkers do. I'm a bit curious why we use instead of for these functions? Using seems to produce the correct results (at least in this simple test): Changing to use those attributes instead seems like a quick, easy fix to resolve this for now. A better solution might be to reserve one CGU and put all of the dead code in that CGU which would sidestep the entire issue by ensuring there is only one CGU with these functions in it.
Let's try it! Are you planning to submit the PR or do you want me to. I think this is harder than it might seem on the surface. If I recall correctly, this was something I looked into, but the information required was not where I needed it, after CGU partitioning. Someone may know a way to do it, but I just want to caution that it might not be that trivial.
Let's see if CI passes
Historical context: See ... My depth of understanding of all of the different linkage options is still more shallow than I'd like. I read the LLVM documentation descriptions several times, but the number of combinations, and their effects, are still hard for me to understand. Some choices I had to make were an "educated guess" on my part. As you can see, MOST of the time, the current linkage works, but if your suggested changes resolve these issues without breaking anything else, that's fantastic.
Ah, thanks! I won't claim my understanding of the linkage options is complete either, but I think will cause the dead code functions' symbols to be made private to the CGU they're declared in and prevent any name collisions by renaming if necessary.

<ins> // compile-flags: -Zinstrument-coverage -Ccodegen-units=4 -Copt-level=0 #![allow(dead_code)] mod foo { #[inline(always)] pub fn called() { } fn uncalled() { } } pub mod bar { pub fn call_me() { super::foo::called(); } } pub mod baz { pub fn call_me() { super::foo::called(); } } </ins>


Question:
Hello, Linking crate on fails when using . The link succeeds when using I expected to see this happen: linking successful. Instead, this happened: :
I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.) So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug... Thanks and sorry for the churn...
Even worth, I suspect you deleted your previous comment :yum:. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed. But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven :smile:
I see is about to be stabilized: Will this issue be solved before stabilization?
I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this? Also note the theory and workaround suggested in I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment). Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too. Thanks! Cc:
Yep, I'll take a look this week!
I hit this with the crate today as well, so any project with in its tree ( for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...
- Did you have any opportunity to look into this?
I'm still looking into this but I have managed to construct a minimal (I believe) repro: Which, with the appropriate flags, will then trigger the link error: There's quite a lot of dead code in the "minimal" repro but removing any of it or even moving it around causes the error to go away. We need basically this exact structure to get the codegen units to be placed into the state which triggers this bug.
Thank you! Having a reproducible example like this is still very helpful. It's not a stretch to assume the trigger relates to the CGU-specific logic in My educated guess (still a guess though) is that we're trying to for the same unused from multiple CGUs. I will try your example on Linux as well, just to be certain this reproducible case really is Windows specific. If it is the CGU logic, and is Windows-specific, the question I have is, what's different between Windows and other platforms like Linux? Some half-baked theories: Codegen on Linux is not actually using multiple codegen units? (Or not as commonly/extensively as on Windows?) I assume this is not the case. Some subtle difference in the parallelism between Windows and Linux is making this situation more likely on Windows? I can't picture how it would be that deterministic on Windows. Differences between the linkers and/or linker parameters, and how they handle duplicate symbols. If so, is this a "bug" in that we can "fix" to make linking on Windows more like linking on the other platforms?
It might also be worth logging the s in that call on line 374, maybe along with identifying the CGU, to confirm that more than one CGU is trying to define the same (unless you already know this to be the case).
- What is the filename for the last chunk of rust code? It doesn't appear to be referenced from any of the other files, unless I'm missing something. I wonder why it gets pulled into the compilation?
Woops, sorry about that! I've updated the comment to include the file name. It's pulled in by the statement in . Codegen on Linux does use multiple cgus (especially when is passed). At least from my tests, is the minimum number of CGUs required to trigger this. I haven't had any issue reproducing with this source (ie, it's not intermittent when the source code is not changed). So it doesn't feel like a parallelism/determinism issue to me. This seems like the most likely issue to me. I'm digging into the symbol table and LLVM IR ...
FYI, I just compiled this on my Linux machine, using , and I a debug message. It does indeed appear to define the same from different CGUs, but it links successfully. This log is printed twice, with two different cgu names:
(In case you'd like to try the same, I this line right before the call to :
Here's another (surprising? to me anyway) clue: I a debug log here: And two CGU's ( shown below and a different CGU) printed identical results: Doesn't this mean that the two CGUs are redundantly generating code for the same 5 functions (6 including the undefined function coverage is adding)? Is there something about the symbols generated for the "used" functions shown here that makes them unique within their CGU, so Windows is not getting linker errors on the used functions as well? Wishful thinking, maybe this identifies an opportunity to improve compiler performance, but more likely I just misunderstood the relationship between the CGUs and the results from the call to .
Ok, that was super helpful and pointed me in the direction of the actual minimal repro. Thanks Since is marked , it's included in the CGU for and the CGU for . Therefore, both CGUs think they should be responsible for generating the unused function and there are two copies of it generated. While the functions are generated as weak symbols, the MSVC linker seems to treat weak symbols differently than unix-y linkers do. I'm a bit curious why we use instead of for these functions? Using seems to produce the correct results (at least in this simple test): Changing to use those attributes instead seems like a quick, easy fix to resolve this for now. A better solution might be to reserve one CGU and put all of the dead code in that CGU which would sidestep the entire issue by ensuring there is only one CGU with these functions in it.
Let's try it! Are you planning to submit the PR or do you want me to. I think this is harder than it might seem on the surface. If I recall correctly, this was something I looked into, but the information required was not where I needed it, after CGU partitioning. Someone may know a way to do it, but I just want to caution that it might not be that trivial.
Let's see if CI passes
Historical context: See ... My depth of understanding of all of the different linkage options is still more shallow than I'd like. I read the LLVM documentation descriptions several times, but the number of combinations, and their effects, are still hard for me to understand. Some choices I had to make were an "educated guess" on my part. As you can see, MOST of the time, the current linkage works, but if your suggested changes resolve these issues without breaking anything else, that's fantastic.
Ah, thanks! I won't claim my understanding of the linkage options is complete either, but I think will cause the dead code functions' symbols to be made private to the CGU they're declared in and prevent any name collisions by renaming if necessary.

<ins> // compile-flags: -Zinstrument-coverage -Ccodegen-units=4 --crate-type dylib -Copt-level=0 // build-pass // needs-profiler-support // Regression test for #85461 where MSVC sometimes fails to link instrument-coverage binaries // with dead code and #[inline(always)]. #![allow(dead_code)] mod foo { #[inline(always)] pub fn called() { } fn uncalled() { } } pub mod bar { pub fn call_me() { super::foo::called(); } } pub mod baz { pub fn call_me() { super::foo::called(); } } </ins>


Question:
I was experimenting with some code on godbolt, when encountering this: with produces the expected assembly: However, when adding (into the same file) this function: The previous function's codegen changes to The issue: it stores the result on the stack, and then immediately discards that. (which it didn't do previously) The second potential issue I'm unsure about is, that here a function's codegen changes by just adding removing seemingly unrelated functions. I was told on discord this is because the two functions use the same , and adding the second one forces to be generalized to and as opposed to just . But I by far don't know enough to judge whether this is a problem or not, or what it's caused by, but I wanted to mention it.
label +A-codegen +I-slow +T-compiler
What's really weird is that on , it looks like this: But for , we get this:
The reason why the second call makes a difference is that IPSCCP is no longer able to propagate the slice length into various functions early.
I would probably blame this one a LoopDeletion/SROA interaction. LoopDeletion leaves behind this code: And SROA runs directly afterwards, before the phi has been folded, so we don't know that the GEPs actually access constant offsets. Possibly the backedge-breaking in LoopDeletion should also perform some folding, or we need a phase ordering change.
Or possibly IndVars should already be replacing the PHI. Just remembered that we have the replaceLoopPHINodesWithPreheaderValues() transform, which seems like it should be taking care of this.
and together should fix this.

<ins> // min-llvm-version: 15.0.0 // compile-flags: -O #![crate_type = "lib"] #[no_mangle] pub fn u16_be_to_arch(mut data: [u8; 2]) -> [u8; 2] { // CHECK-LABEL: @u16_be_to_arch // CHECK: @llvm.bswap.i16 data.reverse(); data } #[no_mangle] pub fn u32_be_to_arch(mut data: [u8; 4]) -> [u8; 4] { // CHECK-LABEL: @u32_be_to_arch // CHECK: @llvm.bswap.i32 data.reverse(); data } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

let size = u64::try_from(self.force_bits(size, pointer_size)?).unwrap(); let align = vtable.read_ptr_sized(pointer_size * 2)?.check_init()?; let align = u64::try_from(self.force_bits(align, pointer_size)?).unwrap(); <ins> let align = Align::from_bytes(align) .map_err(|e| err_ub_format!("invalid vtable: alignment {}", e))?; </ins> if size >= self.tcx.data_layout.obj_size_bound() { throw_ub_format!(


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

size is bigger than largest supported object" ); } <del> Ok((Size::from_bytes(size), Align::from_bytes(align).unwrap())) </del> <ins> Ok((Size::from_bytes(size), align)) </ins> } }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

<ins> // This test contains code with incorrect vtables in a const context: // - from issue 86132: a trait object with invalid alignment caused an ICE in const eval, and now //   triggers an error // - a similar test that triggers a previously-untested const UB error: emitted close to the above //   error, it checks the correctness of the size trait Trait {} const INVALID_VTABLE_ALIGNMENT: &dyn Trait = unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; //~^ ERROR any use of this value will cause an error //~| WARNING this was previously accepted by the compiler //~| invalid vtable: alignment `1000` is not a power of 2 const INVALID_VTABLE_SIZE: &dyn Trait = unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; //~^ ERROR any use of this value will cause an error //~| WARNING this was previously accepted by the compiler //~| invalid vtable: size is bigger than largest supported object fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

<ins> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:10:14 | LL | / const INVALID_VTABLE_ALIGNMENT: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: alignment `1000` is not a power of 2 | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:16:14 | LL | / const INVALID_VTABLE_SIZE: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: size is bigger than largest supported object | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to 2 previous errors </ins>


Question:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)

} w.write_str(")"); }  w.write_str("
");   w.write_str(""); render_stability_since(w, variant, it, cx.tcx()); w.write_str("
");  document(w, cx, variant, Some(it)); document_non_exhaustive(w, variant);


Question:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)

w.write_str("

"); toggle_close(w); }  render_stability_since(w, variant, it, cx.tcx());  } } let def_id = it.def_id.expect_real();


Question:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)

background: transparent; } <ins> .small-section-header { display: flex; justify-content: space-between; position: relative; } </ins> .small-section-header:hover > .anchor { display: initial; }


Question:
Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .

let sz_a = self.a.size(); if A::MAY_HAVE_SIDE_EFFECT && sz_a > self.len { for _ in 0..sz_a - self.len { <ins> self.a_len -= 1; </ins> self.a.next_back(); } <del> self.a_len = self.len; </del> <ins> debug_assert_eq!(self.a_len, self.len); </ins> } let sz_b = self.b.size(); if B::MAY_HAVE_SIDE_EFFECT && sz_b > self.len {


Question:
Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .

} #[test] <ins> #[cfg(panic = "unwind")] fn test_zip_trusted_random_access_next_back_drop() { use std::panic::catch_unwind; use std::panic::AssertUnwindSafe; let mut counter = 0; let it = [42].iter().map(|e| { let c = counter; counter += 1; if c == 0 { panic!("bomb"); } e }); let it2 = [(); 0].iter(); let mut zip = it.zip(it2); catch_unwind(AssertUnwindSafe(|| { zip.next_back(); })) .unwrap_err(); assert!(zip.next().is_none()); assert_eq!(counter, 1); } #[test] </ins> fn test_double_ended_zip() { let xs = [1, 2, 3, 4, 5, 6]; let ys = [1, 2, 3, 7];


Question:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

use rustc_span::symbol::{kw, sym, Symbol}; use rustc_span::Span; <del> use crate::clean::{self, Attributes, AttributesExt, FakeDefId, GetDefId, ToSource}; </del> <ins> use crate::clean::{ self, Attributes, AttributesExt, FakeDefId, GetDefId, NestedAttributesExt, ToSource, Type, }; </ins> use crate::core::DocContext; use crate::formats::item_type::ItemType;


Question:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

if trait_.def_id() == tcx.lang_items().deref_trait() { super::build_deref_target_impls(cx, &trait_items, ret); } <ins> // Return if the trait itself or any types of the generic parameters are doc(hidden). let mut stack: Vec<&Type> = trait_.iter().collect(); stack.push(&for_); while let Some(ty) = stack.pop() { if let Some(did) = ty.def_id() { if cx.tcx.get_attrs(did).lists(sym::doc).has_word(sym::hidden) { return; } } if let Some(generics) = ty.generics() { stack.extend(generics); } } </ins> if let Some(trait_did) = trait_.def_id() { record_extern_trait(cx, trait_did); }


Question:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

<ins> #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} </ins>