Question: [dependencies] # tidy-alphabetical-start <del> ar_archive_writer = "0.4.0" </del> <ins> ar_archive_writer = "0.4.2" </ins> arrayvec = { version = "0.7", default-features = false } bitflags = "2.4.1" cc = "1.0.90"

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried to build using a simple then . I expected to see this happen: linking success. Instead, this happened: MSVC link returns LNK2005 and fails to the static library. It most recently worked on: 1.77.2 <!-- Provide the version you are using that has the regression. --: This is caused by both and When creating stdlibs, each MR causes the Rust compiler to add an export of ; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from This error will not be found until one consumes the Rust-generated library. I am filing this report to consolidate the ones in and <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged
cc
Using for a rust staticlib seems weird to me but cc
The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here:
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library.
Both: I'm using the Rust-produced static library through , plus a module definition file, to create a dynamic library. This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here:
In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue.
I am still struggling to understand why is needed, at least for MSVC.


Question: [dependencies] # tidy-alphabetical-start <del> ar_archive_writer = "0.4.0" </del> <ins> ar_archive_writer = "0.4.2" </ins> arrayvec = { version = "0.7", default-features = false } bitflags = "2.4.1" cc = "1.0.90"

So the DLL is created here: is used so that the DLL includes every single object in the staticlib, even if it's unneeded or indeed causes conflicts. But then is used to add a which presumably defines what actually gets exported from the DLL. What I'm not understanding is what would be different if, for MSVC, it just linked normally without ? I.e. using instead.
On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. . However, PE-COFF static libraries don't support symbol visibility, so the is there to make all Rust symbols private and keep only the librsvg ones. See e.g. and for consequences of not blocking out symbols like .
Sure but the should work regardless of if is used or not because using the export will force the linker to go looking for the symbol(s) listed in the file. E.g. as a test I have the following static lib (using to make symbols easier to find): Which I compile into a static lib using: rustc -O --crate-type=staticlib And I have the following file: Which for simplicity I compile via rustc but I'm using an empty file and also raw linker arguments: rustc -O --crate-type=cdylib -C link-args=" " This compiles and if I see the two functions I wanted: No std symbols are exported.
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault.
If I repeat the above using even in this simple case I get a bunch of errors, not just : I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC.
All duplicate symbol errors for are caused by That it works without is by accident and likely to break in case of cgu partitioning changes.


Question: [dependencies] # tidy-alphabetical-start <del> ar_archive_writer = "0.4.0" </del> <ins> ar_archive_writer = "0.4.2" </ins> arrayvec = { version = "0.7", default-features = false } bitflags = "2.4.1" cc = "1.0.90"

Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.


Question: fn rustc_tables(&mut self, f: &mut dyn FnMut(&mut Tables<'_>)); } <del> thread_local! { /// A thread local variable that stores a pointer to the tables mapping between TyCtxt /// datastructures and stable MIR datastructures. static TLV: Cell<*mut ()> = const { Cell::new(std::ptr::null_mut()) }; } </del> <ins> // A thread local variable that stores a pointer to the tables mapping between TyCtxt // datastructures and stable MIR datastructures scoped_thread_local! (static TLV: Cell<*mut ()>); </ins> pub fn run(mut context: impl Context, f: impl FnOnce()) { <del> assert!(TLV.get().is_null()); </del> <ins> assert!(!TLV.is_set()); </ins> fn g<'a>(mut context: &mut (dyn Context + 'a), f: impl FnOnce()) { <del> TLV.set(&mut context as *mut &mut _ as _); f(); TLV.replace(std::ptr::null_mut()); </del> <ins> let ptr: *mut () = &mut context as *mut &mut _ as _; TLV.set(&Cell::new(ptr), || { f(); }); </ins> } g(&mut context, f); }

is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself


Question: } } } <ins> #[inline] fn len_utf8(code: u32) -> usize { if code < MAX_ONE_B { 1 } else if code < MAX_TWO_B { 2 } else if code < MAX_THREE_B { 3 } else { 4 } } /// Encodes a raw u32 value as UTF-8 into the provided byte buffer, /// and then returns the subslice of the buffer that contains the encoded character. /// /// Unlike `char::encode_utf8`, this method also handles codepoints in the surrogate range. /// (Creating a `char` in the surrogate range is UB.) /// The result is valid [generalized UTF-8] but not valid UTF-8. /// /// [generalized UTF-8]: https://simonsapin.github.io/wtf-8/#generalized-utf8 /// /// # Panics /// /// Panics if the buffer is not large enough. /// A buffer of length four is large enough to encode any `char`. #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] #[doc(hidden)] #[inline] pub fn encode_utf8_raw(code: u32, dst: &mut [u8]) -> &mut [u8] { let len = len_utf8(code); match (len, &mut dst[..]) { (1, [a, ..]) => { *a = code as u8; } (2, [a, b, ..]) => { *a = (code >> 6 & 0x1F) as u8 | TAG_TWO_B; *b = (code & 0x3F) as u8 | TAG_CONT; } (3, [a, b, c, ..]) => { *a = (code >> 12 & 0x0F) as u8 | TAG_THREE_B; *b = (code >> 6 & 0x3F) as u8 | TAG_CONT; *c = (code & 0x3F) as u8 | TAG_CONT; } (4, [a, b, c, d, ..]) => { *a = (code >> 18 & 0x07) as u8 | TAG_FOUR_B; *b = (code >> 12 & 0x3F) as u8 | TAG_CONT; *c = (code >> 6 & 0x3F) as u8 | TAG_CONT; *d = (code & 0x3F) as u8 | TAG_CONT; } _ => panic!( "encode_utf8: need {} bytes to encode U+{:X}, but the buffer has {}", len, code, dst.len(), ), }; &mut dst[..len] } /// Encodes a raw u32 value as UTF-16 into the provided `u16` buffer, /// and then returns the subslice of the buffer that contains the encoded character. /// /// Unlike `char::encode_utf16`, this method also handles codepoints in the surrogate range. /// (Creating a `char` in the surrogate range is UB.) /// /// # Panics /// /// Panics if the buffer is not large enough. /// A buffer of length 2 is large enough to encode any `char`. #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] #[doc(hidden)] #[inline] pub fn encode_utf16_raw(mut code: u32, dst: &mut [u16]) -> &mut [u16] { // SAFETY: each arm checks whether there are enough bits to write into unsafe { if (code & 0xFFFF) == code && !dst.is_empty() { // The BMP falls through *dst.get_unchecked_mut(0) = code as u16; slice::from_raw_parts_mut(dst.as_mut_ptr(), 1) } else if dst.len() >= 2 { // Supplementary planes break into surrogates. code -= 0x1_0000; *dst.get_unchecked_mut(0) = 0xD800 | ((code >> 10) as u16); *dst.get_unchecked_mut(1) = 0xDC00 | ((code as u16) & 0x3FF); slice::from_raw_parts_mut(dst.as_mut_ptr(), 2) } else { panic!( "encode_utf16: need {} units to encode U+{:X}, but the buffer has {}", from_u32_unchecked(code).len_utf16(), code, dst.len(), ) } } } </ins>

The following program causes UB: Miri says: The problem is this code: This calls unless the new code point is in , but what about surrogates in ? This code is unchanged since its introduction in I am not sure what the intended safety contract of is. That method is not marked but clearly should be -- it calls . So my guess is the safety precondition is that must not be part of a surrogate pair, but the thing is, calls it without actually ensuring that condition. The condition it does ensure is that the codepoint is not in , but that does not help.
is excluded from Unicode scalar values a.k.a. , but it’s fine as a Unicode code point. I think this bug is not in the contract of (which is private anyway) but in its implementation, namely going through . The fix is to either duplicate the logic of into , or (to avoid duplication) move that logic to a new function in libcore that takes a parameter and that is called by both and . This function would need to be public because is in a different crate, but it should be prema-unstable and .
I would classify the priority of this bug as low. Although this call to is UB, I expect Miri checking for it explicitly is the only case where that has any consequence in today’s implementation: behaves as expected (for the purpose of WTF-8) in the surrogate range and does not exploit this UB The "layout" of in rustc excludes values beyond but not surrogates:
By the way, the docs at feel insufficient: Which values are invalid? Similarly, and say that represents Unicode Scalar values, but I couldn’t find it documented anywhere that constructing an out of range is Undefined Behavior rather than "merely" a logic bug. Is this specified elsewhere? What is the closest we have to a written down normative resource that specifies what is or isn’t UB in the the Rust language? (For APIs I assume this is the responsibility of their respective doc-comments.)
I agree the impact is low, but it's not just Miri -- this blocks , which is how I discovered the problem. That would be
But then what is "unchecked" about it? Elsewhere in that file the code is careful not to construct a from a without checking for surrogates: That made me assume the author was aware that surrogates in are UB.


Question: } } } <ins> #[inline] fn len_utf8(code: u32) -> usize { if code < MAX_ONE_B { 1 } else if code < MAX_TWO_B { 2 } else if code < MAX_THREE_B { 3 } else { 4 } } /// Encodes a raw u32 value as UTF-8 into the provided byte buffer, /// and then returns the subslice of the buffer that contains the encoded character. /// /// Unlike `char::encode_utf8`, this method also handles codepoints in the surrogate range. /// (Creating a `char` in the surrogate range is UB.) /// The result is valid [generalized UTF-8] but not valid UTF-8. /// /// [generalized UTF-8]: https://simonsapin.github.io/wtf-8/#generalized-utf8 /// /// # Panics /// /// Panics if the buffer is not large enough. /// A buffer of length four is large enough to encode any `char`. #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] #[doc(hidden)] #[inline] pub fn encode_utf8_raw(code: u32, dst: &mut [u8]) -> &mut [u8] { let len = len_utf8(code); match (len, &mut dst[..]) { (1, [a, ..]) => { *a = code as u8; } (2, [a, b, ..]) => { *a = (code >> 6 & 0x1F) as u8 | TAG_TWO_B; *b = (code & 0x3F) as u8 | TAG_CONT; } (3, [a, b, c, ..]) => { *a = (code >> 12 & 0x0F) as u8 | TAG_THREE_B; *b = (code >> 6 & 0x3F) as u8 | TAG_CONT; *c = (code & 0x3F) as u8 | TAG_CONT; } (4, [a, b, c, d, ..]) => { *a = (code >> 18 & 0x07) as u8 | TAG_FOUR_B; *b = (code >> 12 & 0x3F) as u8 | TAG_CONT; *c = (code >> 6 & 0x3F) as u8 | TAG_CONT; *d = (code & 0x3F) as u8 | TAG_CONT; } _ => panic!( "encode_utf8: need {} bytes to encode U+{:X}, but the buffer has {}", len, code, dst.len(), ), }; &mut dst[..len] } /// Encodes a raw u32 value as UTF-16 into the provided `u16` buffer, /// and then returns the subslice of the buffer that contains the encoded character. /// /// Unlike `char::encode_utf16`, this method also handles codepoints in the surrogate range. /// (Creating a `char` in the surrogate range is UB.) /// /// # Panics /// /// Panics if the buffer is not large enough. /// A buffer of length 2 is large enough to encode any `char`. #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] #[doc(hidden)] #[inline] pub fn encode_utf16_raw(mut code: u32, dst: &mut [u16]) -> &mut [u16] { // SAFETY: each arm checks whether there are enough bits to write into unsafe { if (code & 0xFFFF) == code && !dst.is_empty() { // The BMP falls through *dst.get_unchecked_mut(0) = code as u16; slice::from_raw_parts_mut(dst.as_mut_ptr(), 1) } else if dst.len() >= 2 { // Supplementary planes break into surrogates. code -= 0x1_0000; *dst.get_unchecked_mut(0) = 0xD800 | ((code >> 10) as u16); *dst.get_unchecked_mut(1) = 0xDC00 | ((code as u16) & 0x3FF); slice::from_raw_parts_mut(dst.as_mut_ptr(), 2) } else { panic!( "encode_utf16: need {} units to encode U+{:X}, but the buffer has {}", from_u32_unchecked(code).len_utf16(), code, dst.len(), ) } } } </ins>

The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.


Question: LLVMInitializeMSP430Target, LLVMInitializeMSP430TargetMC, LLVMInitializeMSP430AsmPrinter); <ins> init_target!(all(llvm_component = "msp430", llvm_has_msp430_asm_parser), LLVMInitializeMSP430AsmParser); </ins> init_target!(llvm_component = "riscv", LLVMInitializeRISCVTargetInfo, LLVMInitializeRISCVTarget,

Every Rust nightly as of approximately Jan 27, 2019 has to build my msp430 application due to assembler errors of the following form: This is due to in the LLVM backend that has been , but hasn't managed to propagate downstream to yet (thank you for the help). As I understand it, Rust only updates the LLVM backend occassionally, along with some patches; Is it possible to cherry pick this patch so that the msp430 backend works again before the next version bump? I would open this issue on the Rust LLVM fork, but Issues seems to be disabled for this repository...
I think we're generally speaking tracking trunk quite closely so should be feasible to bump here, cc
Friendly ping... has there been any update on this? I'd host my own copy of LLVM with the fix for the time being, but I doubt CI would like that...
pointed me to . Doesn't seem too difficult to follow; I think I should be able to do this myself, hopefully within the week, but at the very least soon :).
Rust now uses LLVM 9, could you try with recent nightly?
It was fun while it lasted. The transition to LLVM 9 causes a separate in my AT2XT repo<sup1</sup, so I'm unsure if we've regressed and this particular issue still applies, or if this is simply a totally separate error and the "r2" error was still fixed. Unfortunately, due to illness, I don't think I can work on this for about another week. Could you ping me again then please if I haven't responded at all. I'll just send another LLVM patch if necessary since I know how to do it now. (cc: Have you seen this? msp430 Rust still shouldn't be using LLVM's assembler for msp430 AFAIK. It may be ready for use however.)
You can try enabling it here but I have no idea if it works at all:
I'm looking into this for two evenings already, but still not found where the bug is. What I know so far: 1) Compiling with and both fail, which means it's probably not a issue, because doesn't need option. 2) Compiling with flag and then using to produce the assembly works fine. Which means the bug is specific to how Rust invokes LLVM.


Question: LLVMInitializeMSP430Target, LLVMInitializeMSP430TargetMC, LLVMInitializeMSP430AsmPrinter); <ins> init_target!(all(llvm_component = "msp430", llvm_has_msp430_asm_parser), LLVMInitializeMSP430AsmParser); </ins> init_target!(llvm_component = "riscv", LLVMInitializeRISCVTargetInfo, LLVMInitializeRISCVTarget,

I will keep debugging this and post here if I find something more.
For reference, the error: Which means that the MSP430 AsmParser cannot be found (even though it does exist). Looking at we see that we indeed fail to initialize it.
no so long ago the asm parser didn't exist on msp430, the inline assembly was just inserted as is into resulting assembly and everything was fine. What exactly have changed that now the asm parser is required? P.S. We can also get rid of option, since we can also produce object files now too.
The integrated assembler was enabled in , which is why it is now attempted to be used. (The option in rustc does not control this behavior.)
Reopening until there is confirmation that this is fixed...
Thank you for your work. There is still a bit more work to be done to get msp430 compiling again. The fix is involved/breaking, and and I (mainly me) will not be able to fix this until the week of August 11th.
I tested 1.38.0-nightly ( 2019-08-07) and can confirm that this issue has been resolved. I think you can close this now, thank you.


Question: use rustc_hir::def_id::{CrateNum, LOCAL_CRATE}; use rustc_metadata::find_native_static_library; use rustc_middle::middle::dependency_format::Linkage; <ins> use rustc_middle::middle::exported_symbols; </ins> use rustc_middle::middle::exported_symbols::{ExportedSymbol, SymbolExportInfo, SymbolExportKind}; use rustc_middle::ty::TyCtxt; use rustc_session::config::{self, CrateType, DebugInfo, LinkerPluginLto, Lto, OptLevel, Strip};

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. ---rs has been updated with a workaround, so the reproduction described below will need adapting (e.g. check out that repo from around or earlier, since that will not include the workaround in ) problem exhibits itself only with certain numbers of codegen-units. The default setting for codegen-units is host dependent (the default is chosen, in part, as a function of the number of cores the host has available, in order to parallelize the code-generation performed by LLVM). In my own experiments, the problem is masked (does not arise) for codegen-units={1,2,4,8}, and the problem does arise for codegen-units={16,32,64,128,256}. You are best off passing explicit when investigating this, just to ward against that being an invisible factor in the experiments. (bug report follows below) I tried this code: I expected to see this happen: succeeds in debug mode. Instead, this happened: fails in debug mode. *isn't immediately obvious why would cause the problem searched nightlies: from nightly-2023-03-27 to nightly-2023-04-02 regressed nightly: nightly-2023-04-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged --
I forked and minimized the reproducible example down to simply having a type (but not a value) with in a crate (and then adding that proc macro crate as a dependency of another crate). You can find it here: (just run in ) Here is a workaround for the crate:
WG-prioritization assigning priority ().


Question: use rustc_hir::def_id::{CrateNum, LOCAL_CRATE}; use rustc_metadata::find_native_static_library; use rustc_middle::middle::dependency_format::Linkage; <ins> use rustc_middle::middle::exported_symbols; </ins> use rustc_middle::middle::exported_symbols::{ExportedSymbol, SymbolExportInfo, SymbolExportKind}; use rustc_middle::ty::TyCtxt; use rustc_session::config::{self, CrateType, DebugInfo, LinkerPluginLto, Lto, OptLevel, Strip};

label -I-prioritize +P-high +T-compiler
TBH it's not clear to me how alignment checks would end up causing linker errors, but since this seems bisected to , let's at the very least notify the PR's author
I already looked over this and was also mystified. I suppose I could take another look? I know almost completely nothing about wasm so I'm not hopeful.
Builds fine: Same linker error: As a mitigation for the linker error, users may put this in their (for the workspace!) That only helps with the alignment checks, is still not going to work.
I can build the reproducer, unmodified, if I use LLD. Or suggests this might be a link order issue. That would explain why LLD is fine with the link, but GNU's linker isn't. Actually, that doesn't make much sense because our standard library is already at the end of the link. I'm out of ideas :shrug: I think this is somehow dependent on linker details that I don't know and I'm struggling to educate myself on.
reported this same linker error from . It can be reproduced by creating an empty Cargo project, then running then . I have not managed to minimize this reproducer. The errant symbol is which is defined as: This has the same sort of shape as the non-unwinding panics from the alignment checks and from the standard library UB-detecting assertions. searched nightlies: from nightly-2023-01-01 to nightly-2023-06-09 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsSo this bisects to a rollup then can't find the unrolled perf builds. Manual trials identifies as the source of the regression.
A tiny update: it seems like this problem goes away if you use  (and for me, it also didn't reproduce for many other values for number-of-codegen-units; I won't bother enumerating those here). This was somewhat of a surprise. I need to investigate more to figure out what relevance the codegen unit partitioning has to do with this issue.


Question: use rustc_hir::def_id::{CrateNum, LOCAL_CRATE}; use rustc_metadata::find_native_static_library; use rustc_middle::middle::dependency_format::Linkage; <ins> use rustc_middle::middle::exported_symbols; </ins> use rustc_middle::middle::exported_symbols::{ExportedSymbol, SymbolExportInfo, SymbolExportKind}; use rustc_middle::ty::TyCtxt; use rustc_session::config::{self, CrateType, DebugInfo, LinkerPluginLto, Lto, OptLevel, Strip};

If nothing else, it is a halfway decent fallback measure while we continue to investigate the problem.
Wanted to add, that I also ran into this issue. For me, it also occurred while compiling a macro crate. I originally thought it was an issue with , as it happened after I ran a , and the issue was fixed by pinning to a slightly older version: There was a bunch of weird behavior I encountered when trying to uncover the issue. The issue was one. When I made other library upgrade changes, it would cause or fix the breakage. I didn't dive too deeply, but it seems like I was still encountering this issue even when I set the compiler to 1.67. (See this Github Actions build and associated commit: ) So it's possible that going to an old version simply hid the issue, but didn't actually pinpoint where the issue was introduced. Let me know if there's any other information I can provide to help isolate the issue. I've seemingly been able to work around the issue by using , as described earlier: I didn't try the other solution about codegen-units.
One MCVE for the stylist-macros build issue looks like this: Just a stylist-macros crate, with this and : So now I'm switching gears to see if I reduce wasm_bindgen to something smaller, so that we can have a small set of crates to talk about on their own here.
Okay got a pretty impressively tiny MCVE for wasm-bindgen too: In case its not clear, this seems like a pretty simple example that should easily work out of the box. (The use of from the mcve-stylist part of the story seems like an important part of the reproduction.) Still looking. Update: Wow, is it somehow of all things that is causing the problem here? That is ... bizarre, to say the least.
may be relevant. That issue is about not mentioning symbols in the version script such that they don't get exported. Also when applying to the rlib containing the symbols the linker error is fixed, so it seems like the linker doesn't pull in archive members even when the version script mentions it. Edit: For regular dylibs we mention all these symbols in , but for proc macros we only list a couple of internal symbols.


Question: use rustc_hir::def_id::{CrateNum, LOCAL_CRATE}; use rustc_metadata::find_native_static_library; use rustc_middle::middle::dependency_format::Linkage; <ins> use rustc_middle::middle::exported_symbols; </ins> use rustc_middle::middle::exported_symbols::{ExportedSymbol, SymbolExportInfo, SymbolExportKind}; use rustc_middle::ty::TyCtxt; use rustc_session::config::{self, CrateType, DebugInfo, LinkerPluginLto, Lto, OptLevel, Strip};

Edit2: There is a special case for proc macros with the handling to not mention any symbols beyond those required to handle circular dependencies. Fixing should fix this issue too by making the version script a subset of again (apart from a couple of symbols defined outside of archives).
: As an addendum to this: (which was in a rollup, as mentioned) the future-proofing safe-guard of adding to the linker invocation. We can add that same link-arg ourselves as part of further bisection that acts prior to PR . In my own MCVE, when I add that link-arg, I find that the code did compile circa 1.63 even with that flag. The flag stopped working sometime between nightly-2022-08-01 and nightly-2022-08-02. (I have not yet tracked down further than that, since its too old to have per-commit prebuilds archived.) Update: oh, of course, it is almost certainly PR that injected the change in behavior mentioned in the previous paragraph.
See related discussion in https://rust- (I have a branch with a commit that seems to fix this here: ; I hope to have a PR up today, once I get a regression test into place.)


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct A<'a> { func: &'a fn() -> Option<int> } impl<'a> A<'a> { fn call(&self) -> Option<int> { (*self.func)() } } fn foo() -> Option<int> { None } fn create() -> A<'static> { A { func: &foo, //~ ERROR borrowed value does not live long enough } } fn main() { let a = create(); a.call(); } </ins>

Hello! The following dumps core when run on my machine (Ubuntu 12.04 LTS, rust-nightly downloaded today (18th Apr)). Ziad Hatahet confirmed the same on a slightly older version of rust.
There's an extra layer of indirection in that struct definition. A is a pointer to a pointer to a function. A statement like expands to . That's obviously creating a dangling pointer onto the stack which is why it ends up crashing. Adjusting the struct definition to should make things work as you want. There's also a bug in rustc for even letting that program compile. I'm not sure if it's already been run into and filed.
cc
This fixes it: But I didn't quite understand why.
it probably happens to reset that part of the stack to the right value.
p.s. This is still crashing in . Thanks
Nominating, something fishy is going on here.
Here's the simplest possible reduction I could make:
Is the compiler mixing up the function pointer with the actual function code? That is, is like So writing is like , i.e. a non- reference to the function pointer.
It's just creating an alloca, storing the function pointer into it, borrowing that, and returning the borrowed pointer. For example, on the program I get this LLVM IR: Basically, the borrow checker doesn't seem to be in on the joke that is referring to a local alloca.
That is the behaviour I would expect if my statement were true. (The double in the LLVM signature indicates what I was talking about: a function value is already the pointer, and so the name doesn't have lifetime.)
0 backcompat-lang
This is probably a mismatch between trans/mem-categorization. I expect mem-categorization is saying that the "reference to the fn" is a static item, but trans is translating it into an rvalue (and hence on the stack).


Question: <ins> error: range endpoint is out of range for `u8` --> $DIR/issue-109529.rs:4:14 | LL |     for _ in 0..256 as u8 {} |              ------^^^^^^ |              | |              help: use an inclusive range instead: `0..=255` | = note: `#[deny(overflowing_literals)]` on by default error: range endpoint is out of range for `u8` --> $DIR/issue-109529.rs:5:14 | LL |     for _ in 0..(256 as u8) {} |              ^^^^^^^^^^^^^^ | help: use an inclusive range instead | LL |     for _ in 0..=(255 as u8) {} |                 + ~~~ error: aborting due to 2 previous errors </ins>

<!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. mod foo { pub mod bar { pub mod baz { pub fn name() -> &'static str { module_path!() } } } } fn main() { assert_eq!(module_path!(), "issue-18859"); assert_eq!(foo::bar::baz::name(), "issue-18859::foo::bar::baz"); } </ins>

I'm seeing things like this: Those used to be . My first guess is something changed in that handles crates different from modules?
Example code to reproduce the issue: And output:


Question: let (resolver, resolver_caches) = { let (krate, resolver, _) = &*abort_on_err(queries.expansion(), sess).peek(); let resolver_caches = resolver.borrow_mut().access(|resolver| { <del> collect_intra_doc_links::early_resolve_intra_doc_links(resolver, krate, externs) </del> <ins> collect_intra_doc_links::early_resolve_intra_doc_links( resolver, krate, externs, document_private, ) </ins> }); (resolver.clone(), resolver_caches) };

The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.


Question: } } <ins> /// Constructs a new locked handle to the standard input of the current /// process. /// /// Each handle returned is a guard granting locked access to a shared /// global buffer whose access is synchronized via a mutex. If you need /// more explicit control over locking, for example, in a multi-threaded /// program, use the [`io::stdin`] function to obtain an unlocked handle, /// along with the [`Stdin::lock`] method. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Read`] and [`BufRead`] traits for /// accessing the underlying data. /// /// **Note**: The mutex locked by this handle is not reentrant. Even in a /// single-threaded program, calling other code that accesses [`Stdin`] /// could cause a deadlock or panic, if this locked handle is held across /// that call. /// /// ### Note: Windows Portability Consideration /// When operating in a console, the Windows implementation of this stream does not support /// non-UTF-8 byte sequences. Attempting to read bytes that are not valid UTF-8 will return /// an error. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Read}; /// /// fn main() -> io::Result<()> { ///     let mut buffer = String::new(); ///     let mut handle = io::stdin_locked(); /// ///     handle.read_to_string(&mut buffer)?; ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn stdin_locked() -> StdinLock<'static> { stdin().into_locked() } </ins> impl Stdin { /// Locks this handle to the standard input stream, returning a readable /// guard.

Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .


Question: } } <ins> /// Constructs a new locked handle to the standard input of the current /// process. /// /// Each handle returned is a guard granting locked access to a shared /// global buffer whose access is synchronized via a mutex. If you need /// more explicit control over locking, for example, in a multi-threaded /// program, use the [`io::stdin`] function to obtain an unlocked handle, /// along with the [`Stdin::lock`] method. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Read`] and [`BufRead`] traits for /// accessing the underlying data. /// /// **Note**: The mutex locked by this handle is not reentrant. Even in a /// single-threaded program, calling other code that accesses [`Stdin`] /// could cause a deadlock or panic, if this locked handle is held across /// that call. /// /// ### Note: Windows Portability Consideration /// When operating in a console, the Windows implementation of this stream does not support /// non-UTF-8 byte sequences. Attempting to read bytes that are not valid UTF-8 will return /// an error. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Read}; /// /// fn main() -> io::Result<()> { ///     let mut buffer = String::new(); ///     let mut handle = io::stdin_locked(); /// ///     handle.read_to_string(&mut buffer)?; ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn stdin_locked() -> StdinLock<'static> { stdin().into_locked() } </ins> impl Stdin { /// Locks this handle to the standard input stream, returning a readable /// guard.

is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:


Question: if sess.opts.incremental.is_none() { return; } <ins> // This is going to be deleted in finalize_session_directory, so let's not create it if sess.has_errors_or_delayed_span_bugs() { return; } </ins> let query_cache_path = query_cache_path(sess); let dep_graph_path = dep_graph_path(sess);

When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly


Question: # ignore-cross-compile -- compiling C++ code does not work well when cross-compiling <del> # This test case makes sure that native libraries are linked with --whole-archive semantics # when the `-bundle,+whole-archive` modifiers are applied to them. </del> <ins> # This test case makes sure that native libraries are linked with appropriate semantics # when the `[+-]bundle,[+-]whole-archive` modifiers are applied to them. </ins> # # The test works by checking that the resulting executables produce the expected output, # part of which is emitted by otherwise unreferenced C code. If +whole-archive didn't work

I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).


Question: <ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash // We should probably be able to infer the types here. However, this test is checking that we don't // get an ICE in this case. It may be modified later to not be an error. struct Foo<const NUM_BYTES: usize>(pub [u8; NUM_BYTES]); fn main() { let _ = Foo::<3>([1, 2, 3]); //~ ERROR type annotations needed } </ins>

Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:


Question: else { // 10 is not constructed d(10, None) <del> } </del> <ins> }, </ins> ); <del> assert_eq!(get(), vec![3, 8, 7, 1, 2]); </del> <ins> assert_eq!(get(), vec![8, 7, 1, 3, 2]); </ins> } assert_eq!(get(), vec![0, 4, 6, 9, 5]);

<!-- 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: both compiles successfully Instead, this happened: fails to compile <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.


Question: else { // 10 is not constructed d(10, None) <del> } </del> <ins> }, </ins> ); <del> assert_eq!(get(), vec![3, 8, 7, 1, 2]); </del> <ins> assert_eq!(get(), vec![8, 7, 1, 3, 2]); </ins> } assert_eq!(get(), vec![0, 4, 6, 9, 5]);

It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated


Question: // Fudge the receiver, so we can do new inference on it. let possible_rcvr_ty = possible_rcvr_ty.fold_with(&mut fudger); let method = self <del> .lookup_method( </del> <ins> .lookup_method_for_diagnostic( </ins> possible_rcvr_ty, segment, DUMMY_SP, call_expr, binding, <del> args, </del> ) .ok()?; // Unify the method signature with our incompatible arg, to

<!-- 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. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: Use verbose output. .TP fB--externfR fINAMEfR=fIPATHfR <del> Specify where an external rust library is located. </del> <ins> Specify where an external rust library is located. These should match fIexternfR declarations in the crate's source code. </ins> .TP fB--sysrootfR fIPATHfR Override the system root.

Now, run the following You get the following error: A simple fix to this is to add at the beginning of , but that should not be unnecessary. Reproduces on nightly.
This is currently working as intended, the flags only work for specifying the immediate set of dependencies (those listed in ), and transitive dependencies must be found through paths. You can use to make sure that only transitive dependencies are found in those paths.
If that is the intended behavior, then please reopen this issue and mark it as a documentation problem. I cannot find where this distinction is explained. This section of would imply that: / are for use with native libraries only, not even mentioning the KIND. by itself will not actually search for crates in that directory. should be used for telling rust where to locate any crate and is an intuitive solution to errors like For reference, how do you thus indicate to rust where to locate a crate whose filename does not follow the pattern?
Yeah seems reasonable to leave open as a docs issue. Not sure exhaustive documentation should go into the message but the man page could certainly be up. That... can't actually be done I don't think. The only way the compiler looks for transitive dependencies is via where is the name of the crate.


Question: } } <del> // FIXME #31379: We can use methods from imported traits shadowed by non-import items if !binding.is_import() { for glob_binding in resolution.duplicate_globs.iter() { </del> <ins> // We can always use methods from the prelude traits for glob_binding in resolution.duplicate_globs.iter() { if glob_binding.defined_with(DefModifiers::PRELUDE) { </ins> module.shadowed_traits.borrow_mut().push(glob_binding); } }

This compiles: but this doesn't: More generally, a shadowed trait's methods are usable if it is shadowed by an item, but not if it is shadowed by an import. Should methods from shadowed traits be usable?
cc
cc
Nominating for discussion at meeting. Clearly we should be consistent. I'm inclined to think that they should not be available, ever.
I'm of the same thoughts as A new "thing" with the same name as another outer "thing" should not inherit/infer/have/etc. any part of that outer thing. This is the case with , but—according to the presented opinion—it seems like it needs to be made consistent for trait bindings, right?
Is there a reason to shadow traits by name? What happens here is that it must find a method named among the imported traits, and that name has not been shadowed in any way, so it should be callable.
Well, that's the question, isn't it. Imagine then that did have an method -- would you prefer an ambiguity error here, or success?
Ambiguity error if was implemented for in the example (and this error is already implemented). Otherwise it doesn't interfere in any way.
Another more challenging example might be: should the methods from be available, given that it is shadowed by ?
My feeling is that the simplest rule is to say that methods come from "traits that are in scope", and shadowed traits are not in scope. This interpretation is shadowing of items from prelude and globs, which seem like they should clearly not count towards method resolution.
Discussed in meeting and settled on "methods from shadowed traits should be unavailable". triage: P-medium
We also want methods from to be unavailable (from your more challenging example), right?


Question: /// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { <del> unsafe { !self.inner.get().is_null() } </del> <ins> unsafe { !(self.inner)().get().is_null() } </ins> } }

There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?


Question: /// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { <del> unsafe { !self.inner.get().is_null() } </del> <ins> unsafe { !(self.inner)().get().is_null() } </ins> } }

Then the actual borrow of a static is an implementation detail and happens on the thread where the key is used, not where it was itself borrowed.
"I believe the only way #[threadlocal] statics can be safe is by requiring the absence of ." This is wrong, I think. For example, one might use thread local data for intrusive linked lists of hazard pointers. They would be thread local but might still be (one can guarantee existence with scoped threads or in certain circumstances where threads are bound to cores). That said you can obviously come up with other representations. In any case, I've mostly come around to believing that we need a separate lifetime (not just for this, but for things like ensuring that can't catch an error in a thread that changes thread local data, violating exception safety).
Based on what wrote, it seems like the TLS interface requires a that only allows non- data and is still accessible like one. One idea I had of how to enable this in todays Rust is to make generate a unit like struct instead of a . That struct would be and have a impl: According to this could also help with , but I'm not familiar enough with the TLS API in general to really reason about this.
I was expecting the impl to target an intermediary type, not the contents themselves. and have their own APIs to deal with. You would still be about to use the TLS API provided by libstd with thread-safe data, it's just the low-level which would have the requirement. Ideas of thread-local lifetimes predate the removal of from , and I'm not sure how relevant they are anymore. I'm also conflating thread-safe data access and thread lifetime... but how long does a thread live? What would unify with? Actually, there's an... easy solution for this. Somehow we were blinded by language semantics, but their details are fluid. It is trivial to make borrows of behave like borrows of an arbitrary rvalue, allowing the resulting reference to be passed down, but not returned. That would ensure that the the thread is just as alive for such borrows as it is for stack ones. would still require a like has, because it may not be when native TLS is supported. But both their APIs are compatible with such a change.
Wouldn't that limit the usability of thread locals in some cases, though?


Question: /// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { <del> unsafe { !self.inner.get().is_null() } </del> <ins> unsafe { !(self.inner)().get().is_null() } </ins> } }

e.g., wouldn't that make it difficult to have a thread local point to another thread local? Maybe I just have to think about it. (BTW, I'm aware we're just talking about the low-level API :)).
in a , borrows are , I didn't even think of that. First off, a global static shouldn't be allowed to borrow a static. And in general, having borrows in a is going to be difficult to support, except for non- data, because they would be right now. We could disallow borrows or we could give some kind of scope to those borrows. Which makes me think, as a compromise between a lifetime and , there could be a pseudo-(rvalue)-scope. Combined with the ability to leave out in globals' type (or not having a type at all), the scope should bubble up into users of those statics. They would behave as if they were borrowed before everything else in the function where they're used, but still not (and they can't be returned from functions).
There's a few intertwined issues here at play, so I just want to quickly summarize the way I see things: This does not affect as it which has an , which while sound should be fixed, allowing removal of the block for . A borrow of a static should not yield something with the lifetime, as that is clearly not sound. I'm not sure I follow why we might require the types in a are not , I haven't quite followed that. Due the cross-platform requirements of std, however, I believe the best solution here is to use the same strategy as with an indirect accessor to ensure the semantics are the same across platforms that have and those that don't (where a normal is used).
triage: P-medium This is an unstable API so it's not super-high priority to fix, but we should defnitely fix!
requiring that a is not is an easy way to ensure that a borrow of it, while , cannot escape the current thread. I've changed my mind and prefer an rvalue borrow semantic for , but it still is the case that and use non- statics (ignoring the workarounds for ). If was supported everywhere, having rvalue borrow semantics wouldn't hurt the std TLS API (aside from stability issues with ), as the access patterns are already through anonymous lifetimes (references passed to closures).


Question: /// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { <del> unsafe { !self.inner.get().is_null() } </del> <ins> unsafe { !(self.inner)().get().is_null() } </ins> } }

Maybe a combined strategy, where borrows of statics are iff the data is not (and rvalue-like otherwise), might work better and would require fewer changes to the std TLS implementation.
Right, but returning a borrow with a lifetime for a global is unsafe for other reasons (the lifetime of the thread is not ).
how can it be abused without sending it to a different thread?
The actual values themselves do not have a lifetime, so it can be a source of unsafety to advertise otherwise. For example you could stick a into a TLS value with a destructor, but when the destructor runs that pointer could be invalid.


Question: bootstrap_out.display() ) } <ins> config.check_build_rustc_version(); </ins> if rust_info.is_from_tarball() && config.description.is_none() { config.description = Some("built from a source tarball".to_owned());

I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.


Question: bootstrap_out.display() ) } <ins> config.check_build_rustc_version(); </ins> if rust_info.is_from_tarball() && config.description.is_none() { config.description = Some("built from a source tarball".to_owned());

building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.


Question: retained: &mut retained, access_levels: &access_levels, }; <del> krate = stripper.fold_crate(krate); </del> <ins> krate = ImportStripper.fold_crate(stripper.fold_crate(krate)); </ins> } // strip all private implementations of traits

Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?


Question: } let total = arg.layout.size; <ins> if total.bits() > 128 { arg.make_indirect(); return; } </ins> arg.cast_to(Uniform { unit: Reg::i64(), total

I have an issue with rust (now version 1.22.1) on Solaris sparc (64bit). On intel I don't see it. I originally see it as part of Firefox build () I now believe it's rustc issue (though it could be still issue with clang-sys). Any help would be greatly appreciated. Run output looks like: Stack: With tracing: Note that clanggetTranslationUnitCursor isn't called with 'tu' set to 0. I have find out that the issue seems to be with the size of CXCursor structure which is returned: CXCursor is 32 bytes long. But if I tell clang-sys it's 16 bytes everything is perfect (when it's 17 bytes or more it causes the trouble): Following is disassembly when CXCursor is pretended to be just 16 bytes: And now with 17 bytes:
I wrote more minimalistic version of test case which rules out use of clang-sys. On intel it works as expected: But on sparc it looks weird: But with this "hack" it looks better:
Ok. I'm new to both Rust and LLVM. I tried to create for above example llvm-ir data on intel and used llc to build it on sparc. The same result could be seen. Does it mean that that issue is rather in LLVM?! On intel I did: On Sparc I did: The output is bad. See comment above (). [1]
and are wrong; structs up to 32 bytes in size, i.e. 256 bits, are returned in registers. I was also suspicious of this code in general when it was first merged as it doesn't seem very long, and handling mixed float and int structs is a little fiddly. EDIT: Well, actually, should vary based on whether it's an argument (which can be up to 16 bytes) or return value (up to 32 bytes).
Can you please suggest how to implement this? I can confirm that when modifying to contain 256 my above test examples passes as expected (though Firefox still wouldn't build).
As mentioned above. With partial fix Firefox build dies later when it calls . Which takes three arguments and the problematic first one is again 32 bytes long structure ().
Maybe you can suggest a preliminary patch to at least improve the code generation?
Are you sure?


Question: } let total = arg.layout.size; <ins> if total.bits() > 128 { arg.make_indirect(); return; } </ins> arg.cast_to(Uniform { unit: Reg::i64(), total

That doesn't entirely control whether a is passed by value or indirectly, but specifically it handles s which the ABI treats like arrays of primitives (incl. SIMD vectors).


Question: "clippy_lints", "compiletest_rs", "derive-new", <del> "git2", </del> "lazy_static 1.4.0", "regex", "rustc-workspace-hack",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.


Question: matches!(self.kind, ItemKind::Enum(..) | ItemKind::Struct(..) | ItemKind::Union(..)) } <ins> /// Check if this is an [`ItemKind::Struct`] or [`ItemKind::Union`]. pub fn is_struct_or_union(&self) -> bool { matches!(self.kind, ItemKind::Struct(..) | ItemKind::Union(..)) } </ins> expect_methods_self_kind! { expect_extern_crate, Option<Symbol>, ItemKind::ExternCrate(s), *s;

<!-- ICE: Rustc '' 'error: internal compiler error: expected ADT to be an item', 'error: internal compiler error: expected ADT to be an item' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [adtdef] computing ADT definition for [adtdef] computing ADT definition for [typeof] computing type of [inferredoutlivescrate] computing the inferred outlives predicates for items in this crate [inferredoutlivesof] computing inferred outlives predicates of [predicatesdefinedon] computing predicates of [predicatesof] computing predicates of [collectmoditemtypes] collecting item types in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Oh, seems that more checks are needed to prevent unnamed fields from occurring in enums.
claim


Question: }); }; <ins> suite("check-ui", "src/test/ui", "ui", "ui"); </ins> suite("check-rpass-full", "src/test/run-pass-fulldeps", "run-pass", "run-pass-fulldeps"); suite("check-rfail-full", "src/test/run-fail-fulldeps",

Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:


Question: <ins> error[E0599]: no method named `push` found for struct `SmallVec` in the current scope --> $DIR/hash-tyvid-regression-4.rs:23:19 | LL |         node.keys.push(k); |                   ^^^^ method not found in `SmallVec<_, { D * 2 }>` ... LL | struct SmallVec<T, const D: usize> { | ---------------------------------- method `push` not found for this error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

<!-- 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. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- 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
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .


Question: <ins> error[E0599]: no method named `push` found for struct `SmallVec` in the current scope --> $DIR/hash-tyvid-regression-4.rs:23:19 | LL |         node.keys.push(k); |                   ^^^^ method not found in `SmallVec<_, { D * 2 }>` ... LL | struct SmallVec<T, const D: usize> { | ---------------------------------- method `push` not found for this error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

<!-- 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<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.


Question: } try!(self.maybe_print_comment(attr.span.lo)); if attr.node.is_sugared_doc { <del> word(self.writer(), &attr.value_str().unwrap()) </del> <ins> try!(word(self.writer(), &attr.value_str().unwrap())); hardbreak(self.writer()) </ins> } else { match attr.node.style { ast::AttrStyle::Inner => try!(word(self.writer(), "#![")),

This code: When run with produces this invalid code because it's losing a newline: With , however, it produces this syntactically correct code:
Moving this bug over to syntex:
Oops, closed the wrong ticket.


Question: //@aux-build:proc_macro_attr.rs:proc-macro <ins> // Flaky test, see https://github.com/rust-lang/rust/issues/113585. //@ignore-32bit //@ignore-64bit </ins> #![warn(clippy::empty_line_after_outer_attr)] #![allow(clippy::assertions_on_constants)] #![feature(custom_inner_attributes)]

In , clippy CI , and I don't think that can be caused by my PR: <details</detailsCc
Seems same with my PR Did you try to rebase master for you branch? I resolved it in this way.
your problem was different. the problem Ralf is running into is
The error message and failed test case are both same with my failed CI in my new PR
gotcha - in that case the rebase probably didn't do anything except rerun ci - this only fails some of the time. https://rust- has a plausible explanation
See the discussion at https://rust- I believe this is an issue with ui_test.
This is causing lots of problems in CI, so I'm marking it as critical.
I'll leave it up to you on tracking what needs to be done to revert . It looks like you've been working on it in ui_test, but I'm not involved in clippy development, so I probably shouldn't be the one tracking/fixing things. However, if you have questions on the cargo side, let me know.
Thanks! After the next clippy sync (tomorrow) this should be fixed. On the ui_test side, the failure is now protected against being spurious and 100% reproducible. I'll ship that to miri soon to prevent the same thing from happening there.


Question: g: &'tcx hir::Generics, id: ast::NodeId) { if self.should_warn_about_variant(&variant.node) { <del> self.warn_dead_code(variant.node.data.id(), variant.span, variant.node.name, "variant"); </del> <ins> self.warn_dead_code(variant.node.data.id(), variant.span, variant.node.name, "variant", "constructed"); </ins> } else { intravisit::walk_variant(self, variant, g, id); }

I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.


Question: // Make sure nobody calls `drop()` explicitly. self.enforce_illegal_method_limitations(&pick); <del> // If there is a `Self: Sized` bound and `Self` is a trait object, it is possible that // something which derefs to `Self` actually implements the trait and the caller // wanted to make a static dispatch on it but forgot to import the trait. // See test `src/test/ui/issue-35976.rs`. // // In that case, we'll error anyway, but we'll also re-run the search with all traits // in scope, and if we find another method which can be used, we'll output an // appropriate hint suggesting to import the trait. let illegal_sized_bound = self.predicates_require_illegal_sized_bound(&method_predicates); </del> // Add any trait/regions obligations specified on the method's type parameters. // We won't add these if we encountered an illegal sized bound, so that we can use // a custom error in that case.

Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.


Question: COMMON_FLAGS=-Copt-level=2 -Ccodegen-units=1 -Cllvm-args=-disable-preinline <del> # LLVM doesn't support instrumenting binaries that use SEH: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMMON_FLAGS+= -Cpanic=abort endif </del> ifeq ($(UNAME),Darwin) # macOS does not have the `tac` command, but `tail -r` does the same thing TAC := tail -r

LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?


Question: } ty::UnsizeVtable(ref ty_trait, self_ty) => { vtable::check_object_safety(self.tcx(), ty_trait, span); // If the type is `Foo+'a`, ensures that the type // being cast to `Foo+'a` implements `Foo`: vtable::register_object_cast_obligations(self, <del> span, ty_trait, self_ty); </del> <ins> span, ty_trait, self_ty); </ins> // If the type is `Foo+'a`, ensures that the type // being cast to `Foo+'a` outlives `'a`:

cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.


Question: // `PlaceMention` and `AscribeUserType` both evaluate the place, which must not // contain dangling references. <del> PlaceContext::NonUse(NonUseContext::PlaceMention) | </del> <ins> PlaceContext::NonMutatingUse(NonMutatingUseContext::PlaceMention) | </ins> PlaceContext::NonUse(NonUseContext::AscribeUserTy) | PlaceContext::MutatingUse(MutatingUseContext::AddressOf) |

<!-- 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: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-android: FIXME(#10381) </del> // ignore-windows // min-lldb-version: 310

Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:


Question: } #[bench] <ins> fn from_utf8_lossy_100_ascii(bh: &mut BenchHarness) { let s = bytes!("Hello there, the quick brown fox jumped over the lazy dog!  Lorem ipsum dolor sit amet, consectetur. "); assert_eq!(100, s.len()); bh.iter(|| { let _ = from_utf8_lossy(s); }); } #[bench] fn from_utf8_lossy_100_multibyte(bh: &mut BenchHarness) { let s = bytes!("𐌀𐌖𐌋𐌄𐌑𐌉ปรدولة الكويتทศไทย中华𐍅𐌿𐌻𐍆𐌹𐌻𐌰"); assert_eq!(100, s.len()); bh.iter(|| { let _ = from_utf8_lossy(s); }); } #[bench] fn from_utf8_lossy_invalid(bh: &mut BenchHarness) { let s = bytes!("Hello", 0xC0, 0x80, " There", 0xE6, 0x83, " Goodbye"); bh.iter(|| { let _ = from_utf8_lossy(s); }); } #[bench] fn from_utf8_lossy_100_invalid(bh: &mut BenchHarness) { let s = ::vec::from_elem(100, 0xF5u8); bh.iter(|| { let _ = from_utf8_lossy(s); }); } #[bench] </ins> fn bench_with_capacity(bh: &mut BenchHarness) { bh.iter(|| { let _ = with_capacity(100);

We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is


Question: /// Map of capability name to boolean value pub bools: HashMap<String, bool>, /// Map of capability name to numeric value <del> pub numbers: HashMap<String, u16>, </del> <ins> pub numbers: HashMap<String, u32>, </ins> /// Map of capability name to raw (unexpanded) string pub strings: HashMap<String, Vec<u8>>, }

does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .


Question: /// Map of capability name to boolean value pub bools: HashMap<String, bool>, /// Map of capability name to numeric value <del> pub numbers: HashMap<String, u16>, </del> <ins> pub numbers: HashMap<String, u32>, </ins> /// Map of capability name to raw (unexpanded) string pub strings: HashMap<String, Vec<u8>>, }

I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.


Question: * * Strings are a packed UTF-8 representation of text, stored as null * terminated buffers of u8 bytes.  Strings should be indexed in bytes, <del> * for efficiency, but UTF-8 unsafe operations should be avoided.  For * some heavy-duty uses, try extra::rope. </del> <ins> * for efficiency, but UTF-8 unsafe operations should be avoided. </ins> */ use at_vec;

In commit I had to disable one of the rope tests. The purpose of that commit was to fix up a bug in the way operator [] works on strings. In particular it used to let you index up to and including the trailing null; now it considers access to the null byte an index overrun and fails. I tried to figure out exactly what was going on in the rope code for quite a while, and tried adjusting a number of obvious-looking things, but to no avail. I'm not really good with boundary-case arithmetic (are any of us?) and the rope module is a maze of such arithmetic. Sharper minds requested to find the bug. Meanwhile I marked the rope test in question () as ignored. The others seem to work.
Paging
I'll take a look.
There is some discussion on IRC that maybe we should just pitch the rope code as it exists now.
agreed. The code is pretty outdated and the work required to modernize it would probably be similar to the work needed to just re-write it. When I was looking through it, it seemed to be doing some very strange things that I don't think are even close to being safe, so there's that too.


Question: //! These structs are a subset of the ones found in `rustc_errors::json`. <del> //! They are only used for deserialization of JSON output provided by libtest. </del> use std::path::{Path, PathBuf}; use std::str::FromStr;

When a process unexpectedly fails/succeeds, compiletest will often print a full dump of its stdout and stderr for diagnostic purposes. When this happens, calls into , which has special handling for lines starting with . It tries to parse the line as JSON in one of a few known compiler-specific formats, in order to replace it with a more human-friendly message. If the line doesn't match any of those formats (or isn't valid JSON), the extractor code will panic, instead of just printing the line as-is. This is awkward in cases where we actually wanted to print the line as-is anyway, because now the error messages are less helpful. label +A-compiletest
The obvious solution (just make it not panic) is complicated by the fact that is called in multiple places, so it's harder to know whether the error is load-bearing in one of those cases.


Question: <ins> use crate::cmp::{max, min}; </ins> use crate::io::prelude::*; <del> use crate::io::{copy, empty, repeat, sink, Empty, Repeat, SeekFrom, Sink}; </del> <ins> use crate::io::{ copy, empty, repeat, sink, BufWriter, Empty, Repeat, Result, SeekFrom, Sink, DEFAULT_BUF_SIZE, }; </ins> #[test] fn copy_copies() {

I was using std::io::copy from an SSD to memory using , which reported an eye-raising 30 MB/s. Wrapping it in a BufReader (either as the outer or middle layer) made no real difference. So I googled around a bit and found the recommended size was 64KB according to some random Microsoft article, so I decided to copy-paste the std::io::copy implementation and increase the buffer size. This got up to 600 MB/s at about 256KB which sounded a lot more it continued going upwards from there past the point of believability (unless the files were being pulled from RAM as a consequence of my repeated accesses). With a 10MB Vec, I got 228.36 GB/s . Unrealistic values aside, has anybody checked the buffer value to make sure there isn't some huge low-hanging fruit for std::io::copy speeds?
You mention windows. This may be platform-specific behavior. On unix systems I would fadvise on the input file for copying. Googling tells me that the windows equivalent is . Have you tried that?
After a coarse overview, my intuition is that there is some funny business going on with the length determined by and the subsequent calls on the , that could explain the unrealistic results.
It’s possible. The actual times did increase dramatically from the std::io::copy default though - my suspicion is that there is probably some caching to RAM going on or something as cold runs were generally slower than hot runs. This was for some work code that I’m no longer actively developing. I’ll leave this email marked as unread for awhile in case I have some spare time to write a benchmark. I don’t think the other flag that was mentioned is accessible with the default open file api, but in any case it at least appears there’s some low hanging fruit wrt to std::io::copy perf
I tried benchmarking on Windoze before and after changing to (instead of the original ) and the results were slightly worse (up to ~3%) with the modified setup, both on HDD and SSD. However, I'm not sure if my benchmarks were good enough - I was having a hard time tweaking them so that I could see any difference between results for different file sizes.