Question:
This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign

}; use fluent_bundle::{FluentBundle, FluentError, FluentResource}; use fluent_syntax::{ <del> ast::{Attribute, Entry, Identifier, Message}, </del> <ins> ast::{ Attribute, Entry, Expression, Identifier, InlineExpression, Message, Pattern, PatternElement, }, </ins> parser::ParserError, }; use proc_macro::{Diagnostic, Level, Span};


Question:
This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign

}; let mut constants = TokenStream::new(); <ins> let mut messagerefs = Vec::new(); </ins> for entry in resource.entries() { let span = res.krate.span(); <del> if let Entry::Message(Message { id: Identifier { name }, attributes, .. }) = entry { </del> <ins> if let Entry::Message(Message { id: Identifier { name }, attributes, value, .. }) = entry { </ins> let _ = previous_defns.entry(name.to_string()).or_insert(path_span); if name.contains('-') {


Question:
This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign

.emit(); } <ins> if let Some(Pattern { elements }) = value { for elt in elements { if let PatternElement::Placeable { expression: Expression::Inline(InlineExpression::MessageReference { id, .. }), } = elt { messagerefs.push((id.name, *name)); } } } </ins> // Require that the message name starts with the crate name // `hir_typeck_foo_bar` (in `hir_typeck.ftl`) // `const_eval_baz` (in `const_eval.ftl`)


Question:
This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign

} } <ins> for (mref, name) in messagerefs.into_iter() { if !previous_defns.contains_key(mref) { Diagnostic::spanned( path_span, Level::Error, format!("referenced message `{mref}` does not exist (in message `{name}`)"), ) .help(&format!("you may have meant to use a variable reference (`{{${mref}}}`)")) .emit(); } } </ins> if let Err(errs) = bundle.add_resource(resource) { for e in errs { match e {


Question:
This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign

use self::fluent_generated::{DEFAULT_LOCALE_RESOURCES, test_crate_foo, with_hyphens}; } <ins> mod missing_message_ref { use super::fluent_messages; fluent_messages! { missing => "./missing-message-ref.ftl" //~^ ERROR referenced message `message` does not exist } } </ins>


Question:
This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign

| = help: replace any '-'s with '_'s <del> error: aborting due to 10 previous errors </del> <ins> error: referenced message `message` does not exist (in message `missing_message_ref`) --> $DIR/test.rs:104:20 | LL |         missing => "./missing-message-ref.ftl" |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: you may have meant to use a variable reference (`{$message}`) error: aborting due to 11 previous errors </ins> For more information about this error, try `rustc --explain E0428`.


Question:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

"{place_name} {partially_str}moved due to this method call{loop_message}", ), ); let infcx = tcx.infer_ctxt().build(); <ins> // Erase and shadow everything that could be passed to the new infcx. </ins> let ty = tcx.erase_regions(moved_place.ty(self.body, tcx).ty); <ins> let method_substs = tcx.erase_regions(method_substs); </ins> if let ty::Adt(def, substs) = ty.kind() && Some(def.did()) == tcx.lang_items().pin_type() && let ty::Ref(_, _, hir::Mutability::Mut) = substs.type_at(0).kind()


Question:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

<ins> // run-rustfix use std::pin::Pin; fn foo(_: &mut ()) {} fn main() { let mut uwu = (); let mut r = Pin::new(&mut uwu); foo(r.as_mut().get_mut()); foo(r.get_mut()); //~ ERROR use of moved value } </ins>


Question:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

<ins> // run-rustfix use std::pin::Pin; fn foo(_: &mut ()) {} fn main() { let mut uwu = (); let mut r = Pin::new(&mut uwu); foo(r.get_mut()); foo(r.get_mut()); //~ ERROR use of moved value } </ins>


Question:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

<ins> error[E0382]: use of moved value: `r` --> $DIR/pin-mut-reborrow-infer-var-issue-107419.rs:10:9 | LL |     let mut r = Pin::new(&mut uwu); |         ----- move occurs because `r` has type `Pin<&mut ()>`, which does not implement the `Copy` trait LL |     foo(r.get_mut()); |           --------- `r` moved due to this method call LL |     foo(r.get_mut()); |         ^ value used here after move | note: `Pin::<&'a mut T>::get_mut` takes ownership of the receiver `self`, which moves `r` --> $SRC_DIR/core/src/pin.rs:LL:COL help: consider reborrowing the `Pin` instead of moving it | LL |     foo(r.as_mut().get_mut()); |           +++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Example code: In rustc 1.67 stable this generates a number of moves (I suppose for calling convention?) that I don't think need to be there, especially when inlining: See While this is a pretty pointless example, this comes up in situations where you might want to convert a tuple of slices into a struct of slices in order to assign names to the tuple members.
LLVM should probably be able to elide the below and pass the original pointer. label +A-llvm +I-slow
This seems to be resolved on current nightly by & Thanks :tada: (I'm not so sure about an incoming inherent problem on alignment attribute)
Fixed as part of the LLVM 17 update (), needs codegen test.
Making the sum a little more vague than the above code prevents the removal of memcpy. Edit: It seems like not so, precisely, the above argument is a function pointer, not a closure, and I now think function pointers never capture any variables (because of ?, ). So is this another missing opportunity?
Yes, the removal is only allowed in the original example, because the called function is known. It does not work with an unknown function due to missing . Note that the is on the by-value argument of , not the by-reference argument of the function pointer .
That sounds reasonable. Thanks! So, in this case, if the assumption that the function pointer never captures the argument was correct, missing attribution opportunities for the callbase?
I don't think there is any missing attribution opportunity here. In your example, if is nocapture, then that does not imply anything about being nocapture (it's a completely different object). Even if you directly passed through the argument to the call (without intermediate memcpy to alloca), inferring nocapture is still not straightforward, because allows interior captures (i.e. it's possible to capture the pointer within the function, as long as it does not stay captured after the function returns).
(Edit: Now I think that on case, capturing in LLVM might happen. Thanks!

<ins> // Verify that move before the call of the function with noalias, nocapture, readonly. // #107436 // compile-flags: -O // min-llvm-version: 17 #![crate_type = "lib"] #[repr(C)] pub struct ThreeSlices<'a>(&'a [u32], &'a [u32], &'a [u32]); #[no_mangle] pub fn sum_slices(val: ThreeSlices) -> u32 { // CHECK-NOT: memcpy let val = val; sum(&val) } #[no_mangle] #[inline(never)] pub fn sum(val: &ThreeSlices) -> u32 { val.0.iter().sum::<u32>() + val.1.iter().sum::<u32>() + val.2.iter().sum::<u32>() } </ins>


Question:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

self.mark_as_used_if_union(*adt, fields); } } <ins> hir::ExprKind::Closure(cls) => { self.insert_def_id(cls.def_id.to_def_id()); } </ins> _ => (), }


Question:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> // edition: 2021 #![deny(dead_code)] pub fn foo() { let closure = || { fn a() {}   //~ ERROR function `a` is never used }; closure() } pub async fn async_foo() { const A: usize = 1; //~ ERROR constant `A` is never used } fn main() {} </ins>


Question:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> error: function `a` is never used --> $DIR/in-closure.rs:7:12 | LL |         fn a() {} |            ^ | note: the lint level is defined here --> $DIR/in-closure.rs:3:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ error: constant `A` is never used --> $DIR/in-closure.rs:13:11 | LL |     const A: usize = 1; |           ^ error: aborting due to 2 previous errors </ins>


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

// through and constrain Pi. let mut subcomponents = smallvec![]; let mut subvisited = SsoHashSet::new(); <del> compute_components_recursive(tcx, ty.into(), &mut subcomponents, &mut subvisited); </del> <ins> compute_alias_components_recursive(tcx, ty, &mut subcomponents, &mut subvisited); </ins> out.push(Component::EscapingAlias(subcomponents.into_iter().collect())); } }


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

/// /// This should not be used to get the components of `parent` itself. /// Use [push_outlives_components] instead. <del> pub(super) fn compute_components_recursive<'tcx>( </del> <ins> pub(super) fn compute_alias_components_recursive<'tcx>( tcx: TyCtxt<'tcx>, alias_ty: Ty<'tcx>, out: &mut SmallVec<[Component<'tcx>; 4]>, visited: &mut SsoHashSet<GenericArg<'tcx>>, ) { let ty::Alias(kind, alias_ty) = alias_ty.kind() else { bug!() }; let opt_variances = if *kind == ty::Opaque { tcx.variances_of(alias_ty.def_id) } else { &[] }; for (index, child) in alias_ty.substs.iter().enumerate() { if opt_variances.get(index) == Some(&ty::Bivariant) { continue; } if !visited.insert(child) { continue; } match child.unpack() { GenericArgKind::Type(ty) => { compute_components(tcx, ty, out, visited); } GenericArgKind::Lifetime(lt) => { // Ignore late-bound regions. if !lt.is_late_bound() { out.push(Component::Region(lt)); } } GenericArgKind::Const(_) => { compute_components_recursive(tcx, child, out, visited); } } } } /// Collect [Component]s for *all* the substs of `parent`. /// /// This should not be used to get the components of `parent` itself. /// Use [push_outlives_components] instead. fn compute_components_recursive<'tcx>( </ins> tcx: TyCtxt<'tcx>, parent: GenericArg<'tcx>, out: &mut SmallVec<[Component<'tcx>; 4]>,


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

// the problem is to add `T: 'r`, which isn't true. So, if there are no // inference variables, we use a verify constraint instead of adding // edges, which winds up enforcing the same condition. <ins> let is_opaque = alias_ty.kind(self.tcx) == ty::Opaque; </ins> if approx_env_bounds.is_empty() && trait_bounds.is_empty() <del> && (alias_ty.needs_infer() || alias_ty.kind(self.tcx) == ty::Opaque) </del> <ins> && (alias_ty.needs_infer() || is_opaque) </ins> { debug!("no declared bounds"); <del> self.substs_must_outlive(alias_ty.substs, origin, region); </del> <ins> let opt_variances = is_opaque.then(|| self.tcx.variances_of(alias_ty.def_id)); self.substs_must_outlive(alias_ty.substs, origin, region, opt_variances); </ins> return; }


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

self.delegate.push_verify(origin, GenericKind::Alias(alias_ty), region, verify_bound); } <ins> #[instrument(level = "debug", skip(self))] </ins> fn substs_must_outlive( &mut self, substs: SubstsRef<'tcx>, origin: infer::SubregionOrigin<'tcx>, region: ty::Region<'tcx>, <ins> opt_variances: Option<&[ty::Variance]>, </ins> ) { let constraint = origin.to_constraint_category(); <del> for k in substs { </del> <ins> for (index, k) in substs.iter().enumerate() { </ins> match k.unpack() { GenericArgKind::Lifetime(lt) => { <del> self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); </del> <ins> let variance = if let Some(variances) = opt_variances { variances[index] } else { ty::Invariant }; if variance == ty::Invariant { self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); } </ins> } GenericArgKind::Type(ty) => { self.type_must_outlive(origin.clone(), ty, region, constraint);


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

<del> use crate::infer::outlives::components::{compute_components_recursive, Component}; </del> <ins> use crate::infer::outlives::components::{compute_alias_components_recursive, Component}; </ins> use crate::infer::outlives::env::RegionBoundPairs; use crate::infer::region_constraints::VerifyIfEq; use crate::infer::VerifyBound;


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

// see the extensive comment in projection_must_outlive let recursive_bound = { let mut components = smallvec![]; <del> compute_components_recursive(self.tcx, alias_ty_as_ty.into(), &mut components, visited); </del> <ins> compute_alias_components_recursive( self.tcx, alias_ty_as_ty.into(), &mut components, visited, ); </ins> self.bound_from_components(&components, visited) };


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

<ins> // check-pass #![feature(type_alias_impl_trait)] struct MyTy<'a>(Vec<u8>, &'a ()); impl MyTy<'_> { fn one(&mut self) -> &mut impl Sized { &mut self.0 } fn two(&mut self) -> &mut (impl Sized + 'static) { self.one() } } type Opaque<'a> = impl Sized; fn define<'a>() -> Opaque<'a> {} fn test<'a>() { None::<&'static Opaque<'a>>; } fn one<'a, 'b: 'b>() -> &'a impl Sized { &() } fn two<'a, 'b>() { one::<'a, 'b>(); } fn main() {} </ins>


Question:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

<ins> // check-pass #![feature(type_alias_impl_trait)] fn opaque<'a: 'a>() -> impl Sized {} fn assert_static<T: 'static>(_: T) {} fn test_closure() { let closure = |_| { assert_static(opaque()); }; closure(&opaque()); } type Opaque<'a> = impl Sized; fn define<'a>() -> Opaque<'a> {} fn test_tait(_: &Opaque<'_>) { None::<&'static Opaque<'_>>; } fn main() {} </ins>


Question:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

pub fn check_target_feature_trait_unsafe(tcx: TyCtxt<'_>, id: LocalDefId, attr_span: Span) { if let DefKind::AssocFn = tcx.def_kind(id) { let parent_id = tcx.local_parent(id); <del> if let DefKind::Impl { of_trait: true } = tcx.def_kind(parent_id) { </del> <ins> if let DefKind::Trait | DefKind::Impl { of_trait: true } = tcx.def_kind(parent_id) { </ins> tcx.sess .struct_span_err( attr_span,


Question:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

unsafe fn unsf_foo(&self) {} } <ins> trait Qux { #[target_feature(enable = "sse2")] //~^ ERROR cannot be applied to safe trait method fn foo(&self) {} } </ins> fn main() {}


Question:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

error: `#[target_feature(..)]` cannot be applied to safe trait method <ins> --> $DIR/trait-impl.rs:22:5 | LL |     #[target_feature(enable = "sse2")] |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot be applied to safe trait method LL | LL |     fn foo(&self) {} |     ------------- not an `unsafe` function error: `#[target_feature(..)]` cannot be applied to safe trait method </ins> --> $DIR/trait-impl.rs:13:5 | LL |     #[target_feature(enable = "sse2")]


Question:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

LL |     fn foo(&self) {} |     ------------- not an `unsafe` function <del> error: aborting due to previous error </del> <ins> error: aborting due to 2 previous errors </ins>


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

false, ); <del> // HACK: This avoids putting the newly built artifacts in the sysroot if we're using // `download-rustc`, to avoid "multiple candidates for `rmeta`" errors. Technically, that's // not quite right: people can set `download-rustc = true` to download even if there are // changes to the compiler, and in that case ideally we would put the *new* artifacts in the // sysroot, in case there are API changes that should be used by tools.  In practice, // though, that should be very uncommon, and people can still disable download-rustc. if !builder.download_rustc() { let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &librustc_stamp(builder, compiler, target)); } </del> <ins> let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &librustc_stamp(builder, compiler, target)); </ins> } }


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

use std::borrow::Cow; use std::collections::HashSet; use std::env; <ins> use std::ffi::OsStr; </ins> use std::fs; use std::io::prelude::*; use std::io::BufReader;


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

// so its artifacts can't be reused. if builder.download_rustc() && compiler.stage != 0 { // Copy the existing artifacts instead of rebuilding them. <del> // NOTE: this path is only taken for tools linking to rustc-dev. builder.ensure(Sysroot { compiler }); </del> <ins> // NOTE: this path is only taken for tools linking to rustc-dev (including ui-fulldeps tests). let sysroot = builder.ensure(Sysroot { compiler }); let ci_rustc_dir = builder.out.join(&*builder.build.build.triple).join("ci-rustc"); for file in builder.config.rustc_dev_contents() { let src = ci_rustc_dir.join(&file); let dst = sysroot.join(file); if src.is_dir() { t!(fs::create_dir_all(dst)); } else { builder.copy(&src, &dst); } } </ins> return; }


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

} // Copy the compiler into the correct sysroot. <del> builder.cp_r(&builder.ci_rustc_dir(builder.build.build), &sysroot); </del> <ins> // NOTE(#108767): We intentionally don't copy `rustc-dev` artifacts until they're requested with `builder.ensure(Rustc)`. // This fixes an issue where we'd have multiple copies of libc in the sysroot with no way to tell which to load. // There are a few quirks of bootstrap that interact to make this reliable: // 1. The order `Step`s are run is hard-coded in `builder.rs` and not configurable. This //    avoids e.g. reordering `test::UiFulldeps` before `test::Ui` and causing the latter to //    fail because of duplicate metadata. // 2. The sysroot is deleted and recreated between each invocation, so running `x test //    ui-fulldeps && x test ui` can't cause failures. let mut filtered_files = Vec::new(); // Don't trim directories or files that aren't loaded per-target; they can't cause conflicts. let suffix = format!("lib/rustlib/{}/lib", compiler.host); for path in builder.config.rustc_dev_contents() { let path = Path::new(&path); if path.parent().map_or(false, |parent| parent.ends_with(&suffix)) { filtered_files.push(path.file_name().unwrap().to_owned()); } } let filtered_extensions = [OsStr::new("rmeta"), OsStr::new("rlib"), OsStr::new("so")]; let ci_rustc_dir = builder.ci_rustc_dir(builder.config.build); builder.cp_filtered(&ci_rustc_dir, &sysroot, &|path| { if path.extension().map_or(true, |ext| !filtered_extensions.contains(&ext)) { return true; } if !path.parent().map_or(true, |p| p.ends_with(&suffix)) { return true; } if !filtered_files.iter().all(|f| f != path.file_name().unwrap()) { builder.verbose_than(1, &format!("ignoring {}", path.display())); false } else { true } }); </ins> return INTERNER.intern_path(sysroot); }


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

env, ffi::{OsStr, OsString}, fs::{self, File}, <del> io::{BufRead, BufReader, ErrorKind}, </del> <ins> io::{BufRead, BufReader, BufWriter, ErrorKind, Write}, </ins> path::{Path, PathBuf}, process::{Command, Stdio}, };


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

let directory_prefix = Path::new(Path::new(uncompressed_filename).file_stem().unwrap()); // decompress the file <del> let data = t!(File::open(tarball)); </del> <ins> let data = t!(File::open(tarball), format!("file {} not found", tarball.display())); </ins> let decompressor = XzDecoder::new(BufReader::new(data)); let mut tar = tar::Archive::new(decompressor); <ins> // `compile::Sysroot` needs to know the contents of the `rustc-dev` tarball to avoid adding // it to the sysroot unless it was explicitly requested. But parsing the 100 MB tarball is slow. // Cache the entries when we extract it so we only have to read it once. let mut recorded_entries = if dst.ends_with("ci-rustc") && pattern == "rustc-dev" { Some(BufWriter::new(t!(File::create(dst.join(".rustc-dev-contents"))))) } else { None }; </ins> for member in t!(tar.entries()) { let mut member = t!(member); let original_path = t!(member.path()).into_owned();


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

if !t!(member.unpack_in(dst)) { panic!("path traversal attack ??"); } <ins> if let Some(record) = &mut recorded_entries { t!(writeln!(record, "{}", short_path.to_str().unwrap())); } </ins> let src_path = dst.join(original_path); if src_path.is_dir() && dst_path.exists() { continue; } t!(fs::rename(src_path, dst_path)); } <del> t!(fs::remove_dir_all(dst.join(directory_prefix))); </del> <ins> let dst_dir = dst.join(directory_prefix); if dst_dir.exists() { t!(fs::remove_dir_all(&dst_dir), format!("failed to remove {}", dst_dir.display())); } </ins> } /// Returns whether the SHA256 checksum of `path` matches `expected`.


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

Some(rustfmt_path) } <ins> pub(crate) fn rustc_dev_contents(&self) -> Vec<String> { assert!(self.download_rustc()); let ci_rustc_dir = self.out.join(&*self.build.triple).join("ci-rustc"); let rustc_dev_contents_file = t!(File::open(ci_rustc_dir.join(".rustc-dev-contents"))); t!(BufReader::new(rustc_dev_contents_file).lines().collect()) } </ins> pub(crate) fn download_ci_rustc(&self, commit: &str) { self.verbose(&format!("using downloaded stage2 artifacts from CI (commit {commit})"));


Question:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

<ins> // Test that `download-rustc` doesn't put duplicate copies of libc in the sysroot. // check-pass #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:

.iter() .enumerate() .map(|(i, ty)| Argument { <del> name: name_from_pat(&body.params[i].pat), </del> <ins> name: Symbol::intern(&rustc_hir_pretty::param_to_string(&body.params[i])), </ins> type_: ty.clean(cx), }) .collect(),


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:

Path { global: path.global, res: path.res, segments } } <del> crate fn qpath_to_string(p: &hir::QPath<'_>) -> String { let segments = match *p { hir::QPath::Resolved(_, ref path) => &path.segments, hir::QPath::TypeRelative(_, ref segment) => return segment.ident.to_string(), hir::QPath::LangItem(lang_item, ..) => return lang_item.name().to_string(), }; let mut s = String::new(); for (i, seg) in segments.iter().enumerate() { if i > 0 { s.push_str("::"); } if seg.ident.name != kw::PathRoot { s.push_str(&seg.ident.as_str()); } } s } </del> crate fn build_deref_target_impls(cx: &DocContext<'_>, items: &[Item], ret: &mut Vec<Item>) { let tcx = cx.tcx;


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:

} } <del> crate fn name_from_pat(p: &hir::Pat<'_>) -> Symbol { use rustc_hir::*; debug!("trying to get a name from pattern: {:?}", p); Symbol::intern(&match p.kind { PatKind::Wild => return kw::Underscore, PatKind::Binding(_, _, ident, _) => return ident.name, PatKind::TupleStruct(ref p, ..) | PatKind::Path(ref p) => qpath_to_string(p), PatKind::Struct(ref name, ref fields, etc) => format!( "{} {{ {}{} }}", qpath_to_string(name), fields .iter() .map(|fp| format!("{}: {}", fp.ident, name_from_pat(&fp.pat))) .collect::<Vec<String>>() .join(", "), if etc { ", .." } else { "" } ), PatKind::Or(ref pats) => pats .iter() .map(|p| name_from_pat(&**p).to_string()) .collect::<Vec<String>>() .join(" | "), PatKind::Tuple(ref elts, _) => format!( "({})", elts.iter() .map(|p| name_from_pat(&**p).to_string()) .collect::<Vec<String>>() .join(", ") ), PatKind::Box(ref p) => return name_from_pat(&**p), PatKind::Ref(ref p, _) => return name_from_pat(&**p), PatKind::Lit(..) => { warn!( "tried to get argument name from PatKind::Lit, which is silly in function arguments" ); return Symbol::intern("()"); } PatKind::Range(..) => panic!( "tried to get argument name from PatKind::Range,  which is not allowed in function arguments" ), PatKind::Slice(ref begin, ref mid, ref end) => { let begin = begin.iter().map(|p| name_from_pat(&**p).to_string()); let mid = mid.as_ref().map(|p| format!("..{}", name_from_pat(&**p))).into_iter(); let end = end.iter().map(|p| name_from_pat(&**p).to_string()); format!("[{}]", begin.chain(mid).chain(end).collect::<Vec<_>>().join(", ")) } }) } </del> crate fn print_const(cx: &DocContext<'_>, n: &'tcx ty::Const<'_>) -> String { match n.val { ty::ConstKind::Unevaluated(def, _, promoted) => {


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:

<ins> // check-pass fn func(0u8..=255: u8) {} </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:

<ins> #![crate_name = "foo"] // @has foo/fn.f.html // @has - '//*[@class="rust fn"]' 'pub fn f(0u8 ...255: u8)' pub fn f(0u8...255: u8) {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized with : label +S-bug-has-mcve
searched toolchains through Regression in
Alternative: Would the error change if the compiler is built with ?
Triage: This is no longer ICE since today's nightly, I assume fixed it. Marking as E-needs-test just in case regression tests there didn't cover this case. labels: +E-needs-test

<ins> error[E0637]: `&` without an explicit lifetime name cannot be used here --> $DIR/issue-109071.rs:8:17 | LL |     type Item = &[T]; |                 ^ explicit lifetime name needed here error[E0107]: missing generics for struct `Windows` --> $DIR/issue-109071.rs:7:9 | LL | impl<T> Windows { |         ^^^^^^^ expected 1 generic argument | note: struct defined here, with 1 generic parameter: `T` --> $DIR/issue-109071.rs:5:8 | LL | struct Windows<T> {} |        ^^^^^^^ - help: add missing generic argument | LL | impl<T> Windows<T> { |                +++ error[E0658]: inherent associated types are unstable --> $DIR/issue-109071.rs:8:5 | LL |     type Item = &[T]; |     ^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = help: add `#![feature(inherent_associated_types)]` to the crate attributes to enable error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0637, E0658. For more information about an error, try `rustc --explain E0107`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized with : label +S-bug-has-mcve
searched toolchains through Regression in
Alternative: Would the error change if the compiler is built with ?
Triage: This is no longer ICE since today's nightly, I assume fixed it. Marking as E-needs-test just in case regression tests there didn't cover this case. labels: +E-needs-test

<ins> // revisions: with_gate no_gate #![cfg_attr(with_gate, feature(inherent_associated_types))] #![cfg_attr(with_gate, allow(incomplete_features))] struct Windows<T> {} impl<T> Windows { //~ ERROR: missing generics for struct `Windows` type Item = &[T]; //~ ERROR: `&` without an explicit lifetime name cannot be used here //[no_gate]~^ ERROR: inherent associated types are unstable fn next() -> Option<Self::Item> {} } impl<T> Windows<T> { fn T() -> Option<Self::Item> {} } fn main() {} </ins>