jiebi/CodeConvo huggingface dataset:
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
triage: P-medium. Unnominating.

Discussion:
[[package]] name = "byteorder" <del> version = "1.2.7" </del> <ins> version = "1.3.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "94f88df23a25417badc922ab0f5716cc1330e87f71ddd9203b3a3ccd9cedf75d" </del> <ins> checksum = "a7c3dd8985a7111efc5c80b44e23ecdd8c007de8ade3b96595387e812b957cf5" </ins> [[package]] name = "bytes"

"hex", "log", "num-traits", <del> "rand 0.6.1", </del> <ins> "rand 0.7.0", </ins> "rustc-workspace-hack", "rustc_version", "shell-escape",

name = "rustc-workspace-hack" version = "1.0.0" dependencies = [ <del> "byteorder", </del> "crossbeam-utils 0.6.5", "serde", "serde_json",

syntax_pos = { path = "../libsyntax_pos" } backtrace = "0.3.3" parking_lot = "0.9" <del> byteorder = { version = "1.1", features = ["i128"]} </del> <ins> byteorder = { version = "1.3" } </ins> chalk-engine = { version = "0.9.0", default-features=false } rustc_fs_util = { path = "../librustc_fs_util" } smallvec = { version = "0.6.7", features = ["union", "may_dangle"] }

rustc_serialize = { path = "../libserialize", package = "serialize" } syntax = { path = "../libsyntax" } syntax_pos = { path = "../libsyntax_pos" } <del> byteorder = { version = "1.1", features = ["i128"] } </del> <ins> byteorder = { version = "1.3" } </ins> rustc_apfloat = { path = "../librustc_apfloat" } smallvec = { version = "0.6.7", features = ["union", "may_dangle"] }

<del> Subproject commit dd94c7c5a32be2ee0adeeaf9d46f26f14925797c </del> <ins> Subproject commit d88138723780d11ca2c09560111223dc20b9d5f3 </ins>

serde = { version = "1.0.82", features = ['derive'] } serde_json = { version = "1.0.31", features = ["raw_value"] } smallvec = { version = "0.6", features = ['union', 'may_dangle'] } <del> byteorder = { version = "1.2.7", features = ["i128"] } </del> [target.'cfg(not(windows))'.dependencies]
Change:
When trying to use generic function with capnproto structs the compiler fails to infer types correctly. I failed to distil the problem to a smaller size. Capnproto generates code that implements traits like this impl &lt;'a::capnp::traits::Owned&lt;'afor Owned { type Reader = Reader&lt;'a; type Builder = Builder&lt;'a; } <details<summaryError</summary<pre<codeerror: internal compiler error: Encountered errors resolving bounds after type-checking </code</pre</detailsWhich I think can be distilled down to which is the same type. : rustc 1.37.0 ( 2019-08-13) binary: rustc commit-hash: commit-date: 2019-08-13 host: x86_64-unknown-linux-gnu release: 1.37.0 LLVM version: 8.0 My first issue btw, sorry for noobyness.
Please provide the source code needed to reproduce this
It can be found here on the CRASH branch. To compile you need capnproto etc also :/
Here is a self-contained reduced example from that code. It can probably be reduced a lot more.
Is this good enough as MCVE? Edit: Reduced it further
Seems to no longer ICE with modify labels: E-needs-test
searched nightlies: from nightly-2021-05-01 to nightly-2021-09-10 regressed nightly: nightly-2021-08-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Looks like fixed this.

Discussion:
<ins> // build-pass // The ICE didn't happen with `cargo check` but `cargo build`. use std::marker::PhantomData; trait Owned<'a> { type Reader; } impl<'a> Owned<'a> for () { type Reader = (); } trait Handler { fn handle(&self); } struct CtxHandlerWithoutState<M, F> { message_type: PhantomData<M>, _function: F, } impl<M, F> CtxHandlerWithoutState<M, F> { pub fn new(_function: F) -> Self { Self { message_type: PhantomData, _function, } } } impl<'a, M, F> Handler for CtxHandlerWithoutState<M, F> where F: Fn(<M as Owned<'a>>::Reader), M: Owned<'a>, { fn handle(&self) {} } fn e_to_i<M: for<'a> Owned<'a>>(_: <M as Owned<'_>>::Reader) {} fn send_external_to_internal<M>() where M: for<'a> Owned<'a>, { let _: Box<dyn Handler> = Box::new(CtxHandlerWithoutState::<M, _>::new(e_to_i::<M>)); } fn main() { send_external_to_internal::<()>() } </ins>
Change:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.

Discussion:
} #[inline] <del> pub fn mk_lang_item(self, ty: Ty<'tcx>, item: lang_items::LangItem)  -> Ty<'tcx> { let def_id = self.require_lang_item(item, None); self.mk_generic_adt(def_id, ty) </del> <ins> pub fn mk_lang_item(self, ty: Ty<'tcx>, item: lang_items::LangItem)  -> Option<Ty<'tcx>> { let def_id = self.lang_items().require(item).ok()?; Some(self.mk_generic_adt(def_id, ty)) </ins> } #[inline]

error: MethodError<'tcx> ) { let rcvr = &args[0]; <del> let try_alt_rcvr = |err: &mut DiagnosticBuilder<'_>, new_rcvr_t| { if let Ok(pick) = self.lookup_probe( span, segment.ident, new_rcvr_t, rcvr, probe::ProbeScope::AllTraits, ) { err.span_label( pick.item.ident.span, &format!("the method is available for `{}` here", new_rcvr_t), ); </del> <ins> let try_alt_rcvr = |err: &mut DiagnosticBuilder<'_>, rcvr_t, lang_item| { if let Some(new_rcvr_t) = self.tcx.mk_lang_item(rcvr_t, lang_item) { if let Ok(pick) = self.lookup_probe( span, segment.ident, new_rcvr_t, rcvr, probe::ProbeScope::AllTraits, ) { err.span_label( pick.item.ident.span, &format!("the method is available for `{}` here", new_rcvr_t), ); } </ins> } };

// Try alternative arbitrary self types that could fulfill this call. // FIXME: probe for all types that *could* be arbitrary self-types, not // just this whitelist. <del> let box_rcvr_t = self.tcx.mk_box(rcvr_t); try_alt_rcvr(&mut err, box_rcvr_t); let pin_rcvr_t = self.tcx.mk_lang_item( rcvr_t, lang_items::PinTypeLangItem, ); try_alt_rcvr(&mut err, pin_rcvr_t); let arc_rcvr_t = self.tcx.mk_lang_item(rcvr_t, lang_items::Arc); try_alt_rcvr(&mut err, arc_rcvr_t); let rc_rcvr_t = self.tcx.mk_lang_item(rcvr_t, lang_items::Rc); try_alt_rcvr(&mut err, rc_rcvr_t); </del> <ins> try_alt_rcvr(&mut err, rcvr_t, lang_items::OwnedBoxLangItem); try_alt_rcvr(&mut err, rcvr_t, lang_items::PinTypeLangItem); try_alt_rcvr(&mut err, rcvr_t, lang_items::Arc); try_alt_rcvr(&mut err, rcvr_t, lang_items::Rc); </ins> } err.emit(); }

<ins> // compile-flags:-C panic=abort #![no_std] pub struct Foo; fn main() { Foo.bar() //~^ ERROR E0599 } #[panic_handler] fn panic(_info: &core::panic::PanicInfo) -> ! { loop{} } </ins>

<ins> error[E0599]: no method named `bar` found for type `Foo` in the current scope --> $DIR/issue-64430.rs:7:9 | LL | pub struct Foo; | --------------- method `bar` not found for this ... LL |     Foo.bar() |         ^^^ method not found in `Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>
Change:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at

Discussion:
#![feature(bool_to_option)] #![feature(box_patterns)] #![feature(box_syntax)] <del> #![feature(cmp_min_max_by)] </del> #![feature(const_fn)] #![feature(const_panic)] #![feature(core_intrinsics)]

/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::min_by(-2, 1, |x: &i32, y: &i32| x.abs().cmp(&y.abs())), 1);

/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn min_by<T, F: FnOnce(&T, &T) -> Ordering>(v1: T, v2: T, compare: F) -> T { match compare(&v1, &v2) { Ordering::Less | Ordering::Equal => v1,

/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::min_by_key(-2, 1, |x: &i32| x.abs()), 1);

/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn min_by_key<T, F: FnMut(&T) -> K, K: Ord>(v1: T, v2: T, mut f: F) -> T { min_by(v1, v2, |v1, v2| f(v1).cmp(&f(v2))) }

/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::max_by(-2, 1, |x: &i32, y: &i32| x.abs().cmp(&y.abs())), -2);

/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn max_by<T, F: FnOnce(&T, &T) -> Ordering>(v1: T, v2: T, compare: F) -> T { match compare(&v1, &v2) { Ordering::Less | Ordering::Equal => v2,

/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::max_by_key(-2, 1, |x: &i32| x.abs()), -2);

/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn max_by_key<T, F: FnMut(&T) -> K, K: Ord>(v1: T, v2: T, mut f: F) -> T { max_by(v1, v2, |v1, v2| f(v1).cmp(&f(v2))) }

#![feature(iter_partition_in_place)] #![feature(iter_is_partitioned)] #![feature(iter_order_by)] <del> #![feature(cmp_min_max_by)] </del> #![feature(iter_map_while)] #![feature(const_mut_refs)] #![feature(const_pin)]
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Upstream fix has landed:

Discussion:
<del> Subproject commit 412fb00b37afb6b7f7fa96a35f2315c7e640b916 </del> <ins> Subproject commit d9aa23a43ad29e3a10551a1425ef5d5baef28d70 </ins>
Change:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Duplicate of

Discussion:
match param.kind { GenericParamKind::Lifetime { .. } => { let (name, reg) = Region::early(&self.tcx.hir(), &mut index, &param); <ins> let def_id = if let Region::EarlyBound(_ ,def_id , _) = reg { def_id } else { bug!(); }; </ins> if let hir::ParamName::Plain(param_name) = name { if param_name.name == kw::UnderscoreLifetime { // Pick the elided lifetime "definition" if one exists // and use it to make an elision scope. <ins> self.lifetime_uses.insert(def_id.clone(), LifetimeUseSet::Many); </ins> elision = Some(reg); } else { lifetimes.insert(name, reg); } } else { <ins> self.lifetime_uses.insert(def_id.clone(), LifetimeUseSet::Many); </ins> lifetimes.insert(name, reg); } }

_ => None, } { debug!("id = {:?} span = {:?} name = {:?}", id, span, name); if name.name == kw::UnderscoreLifetime { continue; }

<ins> // edition:2018 // Avoid spurious warnings of unused lifetime. The below async functions // are desugered to have an unused lifetime // but we don't want to warn about that as there's nothing they can do about it. #![deny(unused_lifetimes)] #![allow(dead_code)] pub async fn october(s: &str) { println!("{}", s); } pub async fn async_fn(&mut ref s: &mut[i32]) { println!("{:?}", s); } macro_rules! foo_macro { () => { pub async fn async_fn_in_macro(&mut ref _s: &mut[i32]) {} }; } foo_macro!(); pub async fn func_with_unused_lifetime<'a>(s: &'a str) { //~^ ERROR lifetime parameter `'a` never used println!("{}", s); } pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { //~^ ERROR lifetime parameter `'a` never used //~^^ ERROR lifetime parameter `'b` never used println!("{}", s); } pub async fn func_with_unused_lifetime_in_two_params<'c>(s: &'c str, t: &'c str) { //~^ ERROR lifetime parameter `'c` never used println!("{}", s); } fn main() {} </ins>

<ins> error: lifetime parameter `'a` never used --> $DIR/unused-lifetime.rs:26:40 | LL | pub async fn func_with_unused_lifetime<'a>(s: &'a str) { |                                        ^^ | note: lint level defined here --> $DIR/unused-lifetime.rs:7:9 | LL | #![deny(unused_lifetimes)] |         ^^^^^^^^^^^^^^^^ error: lifetime parameter `'a` never used --> $DIR/unused-lifetime.rs:31:44 | LL | pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { |                                            ^^ error: lifetime parameter `'b` never used --> $DIR/unused-lifetime.rs:31:48 | LL | pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { |                                                ^^ error: lifetime parameter `'c` never used --> $DIR/unused-lifetime.rs:37:54 | LL | pub async fn func_with_unused_lifetime_in_two_params<'c>(s: &'c str, t: &'c str) { |                                                      ^^ error: aborting due to 4 previous errors </ins>
Change:
I've noticed today that apparently Rust adds sanitizer runtimes such as the ASan runtime during linking and I found this runtime inside a static archive. As far as I know, these runtimes should not be part of static archives or DSOs, they should only be linked when creating an executable. Adding them to DSOs causes two runtimes to exist when loading the DSO into an ASan binary (we had this problem longer ago in mozilla-central and it was fixed in Clang, see [1]). Adding the runtime to static archives causes linker problems when linking the archive to a C++ binary built with ASan because Clang will add the ASan runtime a second time when linking the executable. For some reason this worked before (maybe if the runtimes used are exactly identical the linker will deduplicate them) but today during building with Rust nightly I got duplicate symbol errors indicating two conflicting ASan RTs. From what I can tell, Rust should not link these runtimes except if it is producing an executable. The respective code is called here independent of : [1]
See also
I'm reopening this because the fix I made is not complete. There is a second place where we inject the sanitizer runtime and that is the function in . It even explicitly attaches the runtime to static libraries. This is a one-line fix but afterwards the test fails. This test failure is expected because the test itself is incorrect as well. I will make another PR that has the fix and also changes the test to include a negative-check for the runtime in staticlibs.
This was fixed in & .

Discussion:
_ if codegen_results.crate_info.profiler_runtime == Some(cnum) => { add_static_crate::<B>(cmd, sess, codegen_results, tmpdir, crate_type, cnum); } <del> _ if codegen_results.crate_info.sanitizer_runtime == Some(cnum) => { </del> <ins> _ if codegen_results.crate_info.sanitizer_runtime == Some(cnum) && crate_type == config::CrateType::Executable => { // Link the sanitizer runtimes only if we are actually producing an executable </ins> link_sanitizer_runtime::<B>(cmd, sess, codegen_results, tmpdir, cnum); } // compiler-builtins are always placed last to ensure that they're
Change:
Following code ICEs on today's nightly ( 2019-09-20): What's peculiar is that no ICE is shown when the enum contains only one item:
Backtrace:
This is because the discriminant assignment code tries to increment the discriminant of the previous variant, which was an error, and thus fails in a different way to the first. However, the code looks like it handles that case, so I'm not yet sure what's going wrong here. Edit: I think there's some state changing inside — the discriminant assignment code seems to be working as expected. is being called with essentially identical arguments, but something about the first error is causing the second one to behave differently.
It's not a regression. Stable shows I don't see how we could be keeping state. Maybe it's happening because there's no "cannot infer type for " error on anything but the first item? So is never evaluated, thus not causing an ICE.
Hmm, perhaps. In that case, it's simplest just to instead.
This , though it does ICE on beta. We now get type inference errors on both variants.
Reopening, as we should have a test.

Discussion:
<ins> enum Foo { A = foo(), //~ ERROR: type annotations needed B = foo(), //~ ERROR: type annotations needed } const fn foo<T>() -> isize { 0 } fn main() {} </ins>

<ins> error[E0282]: type annotations needed --> $DIR/issue-64662.rs:2:9 | LL |     A = foo(), |         ^^^ cannot infer type for `T` error[E0282]: type annotations needed --> $DIR/issue-64662.rs:3:9 | LL |     B = foo(), |         ^^^ cannot infer type for `T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>
Change:
When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!

Discussion:
.emit(); } EscapeError::MoreThanOneChar => { <ins> let msg = if mode.is_bytes() { "if you meant to write a byte string literal, use double quotes" } else { "if you meant to write a `str` literal, use double quotes" }; </ins> handler .struct_span_err( span_with_quotes,

) .span_suggestion( span_with_quotes, <del> "if you meant to write a `str` literal, use double quotes", </del> <ins> msg, </ins> format!(""{}"", lit), Applicability::MachineApplicable, ).emit()

<ins> #![allow(unused)] fn main() { let _foo = b'hello0'; //~^ ERROR character literal may only contain one codepoint //~| HELP if you meant to write a byte string literal, use double quotes let _bar = 'hello'; //~^ ERROR character literal may only contain one codepoint //~| HELP if you meant to write a `str` literal, use double quotes } </ins>

<ins> error: character literal may only contain one codepoint --> $DIR/issue-64732.rs:3:17 | LL |     let _foo = b'hello0'; |                 ^^^^^^^^^ help: if you meant to write a byte string literal, use double quotes | LL |     let _foo = b"hello0"; |                 ^^^^^^^^^ error: character literal may only contain one codepoint --> $DIR/issue-64732.rs:6:16 | LL |     let _bar = 'hello'; |                ^^^^^^^ help: if you meant to write a `str` literal, use double quotes | LL |     let _bar = "hello"; |                ^^^^^^^ error: aborting due to 2 previous errors </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I suspect miri just needs a compiletest update cc
triage: P-medium. Removing nomination label.
So, the compiletest-update was semver-breaking?
The failure seems to be a panic in cargo...?
not quite, nightly rustc broke compiletest and we play catch up with that since the nightly feature is "current nightly" the cargo panic you're seeing is an osx bug in cargo that got fixed
Is this a recent bug? It looks (in Miri CI) as if the bug occurred with stable cargo.
this bug appeared in nightly and got fixed on the next day. Could you cargo version from CI (after installing master toolchain)?
It's recent, but not on stable, maybe you're seeing something else.
FWIW, the trouble was that Travis on the auto branch used a beta cargo, not a stable one, due to caching.

Discussion:
"serde_derive", "serde_json", "tempfile", <del> "tester", </del> "winapi 0.3.6", ]

[[package]] name = "term" <del> version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "fa63644f74ce96fbeb9b794f66aff2a52d601cbd5e80f4b97123e3899f4570f1" dependencies = [ "kernel32-sys", "winapi 0.2.8", ] [[package]] name = "term" </del> version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "0dd90505d5006a4422d3520b30c781d480b3f36768c2fa2187c3e950bc110464"

] [[package]] <del> name = "tester" version = "0.5.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "5e812cb26c597f86a49b26dbb58b878bd2a2b4b93fc069dc39499228fe556ff6" dependencies = [ "getopts", "libc", "term 0.4.6", ] [[package]] </del> name = "textwrap" version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index"

<del> Subproject commit 130f9488d3b861e02c9282b686eec717e30912cf </del> <ins> Subproject commit 07ac10277ea5ad42efbb914da5844e0ab08efbf4 </ins>
Change:
Compiling this: Results in an ICE: Different error on nightly: Backtrace for stable:
triage: tagging as P-high for initial investigation as to severity. Doesn't seem like it warrants discussion at T-compiler meeting. Removing nomination tag.
I'll try to look at this during the weekend. This is not a regression, so the priority is probably not especially high.
Fixed in

Discussion:
check_consistency(self, &[seg], ident.span, kind, initial_res, res); } Err(..) => { <del> assert!(initial_binding.is_none()); </del> let expected = kind.descr_expected(); let msg = format!("cannot find {} `{}` in this scope", expected, ident); let mut err = self.session.struct_span_err(ident.span, &msg);

<ins> // Regression test for issue #64803 (initial attribute resolution can disappear later). // aux-build:test-macros.rs #[macro_use] extern crate test_macros; mod m { use test_macros::Empty; } use m::Empty; //~ ERROR derive macro `Empty` is private // To resolve `empty_helper` we need to resolve `Empty`. // During initial resolution `use m::Empty` introduces no entries, so we proceed to `macro_use`, // successfully resolve `Empty` from there, and then resolve `empty_helper` as its helper. // During validation `use m::Empty` introduces a `Res::Err` stub, so `Empty` resolves to it, // and `empty_helper` can no longer be resolved. #[empty_helper] //~ ERROR cannot find attribute `empty_helper` in this scope #[derive(Empty)] struct S; fn main() {} </ins>

<ins> error: cannot find attribute `empty_helper` in this scope --> $DIR/disappearing-resolution.rs:18:3 | LL | #[empty_helper] |   ^^^^^^^^^^^^ error[E0603]: derive macro `Empty` is private --> $DIR/disappearing-resolution.rs:11:8 | LL | use m::Empty; |        ^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0603`. </ins>