Question: <ins> error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-89064.rs:17:16 | LL |     let _ = A::foo::<S>(); |                ^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-89064.rs:4:8 | LL |     fn foo() {} |        ^^^ help: consider moving this generic argument to the `A` trait, which takes up to 1 argument | LL -     let _ = A::foo::<S>(); LL +     let _ = A::<S>::foo(); | help: remove these generics | LL -     let _ = A::foo::<S>(); LL +     let _ = A::foo(); | error[E0107]: this associated function takes 0 generic arguments but 2 generic arguments were supplied --> $DIR/issue-89064.rs:22:16 | LL |     let _ = B::bar::<S, S>(); |                ^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-89064.rs:8:8 | LL |     fn bar() {} |        ^^^ help: consider moving these generic arguments to the `B` trait, which takes up to 2 arguments | LL -     let _ = B::bar::<S, S>(); LL +     let _ = B::<S, S>::bar(); | help: remove these generics | LL -     let _ = B::bar::<S, S>(); LL +     let _ = B::bar(); | error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-89064.rs:27:21 | LL |     let _ = A::<S>::foo::<S>(); |                     ^^^----- help: remove these generics |                     | |                     expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-89064.rs:4:8 | LL |     fn foo() {} |        ^^^ error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-89064.rs:31:16 | LL |     let _ = 42.into::<Option<_>>(); |                ^^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn into(self) -> T; |        ^^^^ help: consider moving this generic argument to the `Into` trait, which takes up to 1 argument | LL |     let _ = Into::<Option<_>>::into(42); |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     let _ = 42.into::<Option<_>>(); LL +     let _ = 42.into(); | error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0107`. </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

I got this while trying to implement something similar to a FromStr trait and tried to rely on a lot of inferencing when calling it. I can try to extract a standalone example if needed.
This ICE is also producible by trying to refer to an associated type that's never defined. is accepted by the compiler when it clearly should not be - what on earth is ? The following and code cases the same ICE. Here's the stack trace:


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

I get the ICE below when I compile this fragment of code: The above structs are defined here: The above fragment is part of That crate depends on And that crate requires erlang-17.4 to be installed.
A minimal program to demonstrate the crash is...


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

compile with opt-level = 2 (works fine with opt-level=0)
strange. the program looks legit to me.
this works for me now, as of
This prints on all opt levels for me at .


Question: ConditionalPass::always(CHECK_CUSTOM_CODE_CLASSES), ConditionalPass::always(COLLECT_TRAIT_IMPLS), ConditionalPass::always(CHECK_DOC_TEST_VISIBILITY), <ins> ConditionalPass::always(STRIP_ALIASED_NON_LOCAL), </ins> ConditionalPass::new(STRIP_HIDDEN, WhenNotDocumentHidden), ConditionalPass::new(STRIP_PRIVATE, WhenNotDocumentPrivate), ConditionalPass::new(STRIP_PRIV_IMPORTS, WhenDocumentPrivate),

I tried this code: with and . I expected to see this happen: No internal fields of the should be displayed as users won't be able to use the fields, making their appearance confusing and useless. Instead, this happened: The internal fields of the are displayed ! Real impact as can be seen . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
labels +T-rustdoc +A-rustdoc-ui -needs-triage claim
Dupe of and more discussion there


Question: ConditionalPass::always(CHECK_CUSTOM_CODE_CLASSES), ConditionalPass::always(COLLECT_TRAIT_IMPLS), ConditionalPass::always(CHECK_DOC_TEST_VISIBILITY), <ins> ConditionalPass::always(STRIP_ALIASED_NON_LOCAL), </ins> ConditionalPass::new(STRIP_HIDDEN, WhenNotDocumentHidden), ConditionalPass::new(STRIP_PRIVATE, WhenNotDocumentPrivate), ConditionalPass::new(STRIP_PRIV_IMPORTS, WhenDocumentPrivate),

Using to document private types of the current workspace exposes external types private implementation details (in this case private fields). I would expect the expansion to limit itself to public fields. e.g. gives ! <details<summary<coderustc --version --verbose</code</summary<p</p</detailsr?
I suppose it's "ok" since you used the option. I'll add it to the next rustdoc team meeting agenda to be confirmed by the team.
Rendered output for anyone wondering: !
I'll summarize the exchange I had with Guillaume on matrix. First, the flag I'm talking about is the one you provide to . does not blindly pass the flag to but only for crates you own in your current workspace. That means that when documenting your workspace with . Private items, fields of your crates are shown contrary to your dependencies. Regarding design, it seems weird to me that aliased type expansion shows private implementation details of dependencies (e.g. for the given example). I would personally expect something like:


Question: | (ProjectionElem::Index(..), ProjectionElem::ConstantIndex { .. }) | (ProjectionElem::Index(..), ProjectionElem::Subslice { .. }) | (ProjectionElem::ConstantIndex { .. }, ProjectionElem::Index(..)) <del> | (ProjectionElem::ConstantIndex { .. }, ProjectionElem::ConstantIndex { .. }) | (ProjectionElem::ConstantIndex { .. }, ProjectionElem::Subslice { .. }) | (ProjectionElem::Subslice { .. }, ProjectionElem::Index(..)) | (ProjectionElem::Subslice { .. }, ProjectionElem::ConstantIndex { .. }) | (ProjectionElem::Subslice { .. }, ProjectionElem::Subslice { .. }) => { </del> <ins> | (ProjectionElem::Subslice { .. }, ProjectionElem::Index(..)) => { </ins> // Array indexes (`a[0]` vs. `a[i]`). These can either be disjoint // (if the indexes differ) or equal (if they are the same), so this // is the recursive case that gives "equal *or* disjoint" its meaning. <del> // // Note that by construction, MIR at borrowck can't subdivide // `Subslice` accesses (e.g. `a[2..3][i]` will never be present) - they // are only present in slice patterns, and we "merge together" nested // slice patterns. That means we don't have to think about these. It's // probably a good idea to assert this somewhere, but I'm too lazy. // // FIXME(#8636) we might want to return Disjoint if // both projections are constant and disjoint. debug!("place_element_conflict: DISJOINT-OR-EQ-ARRAY"); </del> <ins> debug!("place_element_conflict: DISJOINT-OR-EQ-ARRAY-INDEX"); </ins> Overlap::EqualOrDisjoint } <ins> (ProjectionElem::ConstantIndex { offset: o1, min_length: _, from_end: false }, ProjectionElem::ConstantIndex { offset: o2, min_length: _, from_end: false }) | (ProjectionElem::ConstantIndex { offset: o1, min_length: _, from_end: true }, ProjectionElem::ConstantIndex { offset: o2, min_length: _, from_end: true }) => { if o1 == o2 { debug!("place_element_conflict: DISJOINT-OR-EQ-ARRAY-CONSTANT-INDEX"); Overlap::EqualOrDisjoint } else { debug!("place_element_conflict: DISJOINT-ARRAY-CONSTANT-INDEX"); Overlap::Disjoint } } (ProjectionElem::ConstantIndex { offset: offset_from_begin, min_length: min_length1, from_end: false }, ProjectionElem::ConstantIndex { offset: offset_from_end, min_length: min_length2, from_end: true }) | (ProjectionElem::ConstantIndex { offset: offset_from_end, min_length: min_length1, from_end: true }, ProjectionElem::ConstantIndex { offset: offset_from_begin, min_length: min_length2, from_end: false }) => { // both patterns matched so it must be at least the greater of the two let min_length = max(min_length1, min_length2); // `offset_from_end` can be in range `[1..min_length]`, 1 indicates the last // element (like -1 in Python) and `min_length` the first. // Therefore, `min_length - offset_from_end` gives the minimal possible // offset from the beginning if *offset_from_begin >= min_length - offset_from_end { debug!("place_element_conflict: DISJOINT-OR-EQ-ARRAY-CONSTANT-INDEX-FE"); Overlap::EqualOrDisjoint } else { debug!("place_element_conflict: DISJOINT-ARRAY-CONSTANT-INDEX-FE"); Overlap::Disjoint } } (ProjectionElem::ConstantIndex { offset, min_length: _, from_end: false }, ProjectionElem::Subslice {from, .. }) | (ProjectionElem::Subslice {from, .. }, ProjectionElem::ConstantIndex { offset, min_length: _, from_end: false }) => { if offset >= from { debug!( "place_element_conflict: DISJOINT-OR-EQ-ARRAY-CONSTANT-INDEX-SUBSLICE"); Overlap::EqualOrDisjoint } else { debug!("place_element_conflict: DISJOINT-ARRAY-CONSTANT-INDEX-SUBSLICE"); Overlap::Disjoint } } (ProjectionElem::ConstantIndex { offset, min_length: _, from_end: true }, ProjectionElem::Subslice {from: _, to }) | (ProjectionElem::Subslice {from: _, to }, ProjectionElem::ConstantIndex { offset, min_length: _, from_end: true }) => { if offset > to { debug!("place_element_conflict:  DISJOINT-OR-EQ-ARRAY-CONSTANT-INDEX-SUBSLICE-FE"); Overlap::EqualOrDisjoint } else { debug!("place_element_conflict: DISJOINT-ARRAY-CONSTANT-INDEX-SUBSLICE-FE"); Overlap::Disjoint } } (ProjectionElem::Subslice { .. }, ProjectionElem::Subslice { .. }) => { debug!("place_element_conflict: DISJOINT-OR-EQ-ARRAY-SUBSLICES"); Overlap::EqualOrDisjoint } </ins> (ProjectionElem::Deref, _) | (ProjectionElem::Field(..), _) | (ProjectionElem::Index(..), _)

Minimal example: This will complain about multiple mutable borrows, even though it should be valid.
Noted in (but may deserve a separate bug report?). (FYI, slice patterns are unstable for a reason; they're pretty buggy at the moment).
should be closed after MIR borrowck will be by default


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Regression test for issue #25436: check that things which can be // followed by any token also permit X* to come afterwards. macro_rules! foo { ( $a:expr $($b:tt)* ) => { }; //~ ERROR not allowed for `expr` fragments ( $a:ty $($b:tt)* ) => { };   //~ ERROR not allowed for `ty` fragments } fn main() { } </ins>

In an example like we report the following error: This is part of the macro future-proofing code but it is an unnecessary limitation. For fragments that represent at most one token tree (, , , possibly others) there is no concern at all about being following by sequence repetition. This turns out to be a really big limitation in practice, since making macros that work over a generic sequence of token trees effectively allows for arbitrary parsing. cc
triage: P-medium
I'd be happy to mentor this, if I don't fix it first.
triage: P-medium
cc
I-ICE?
Curious why this was closed, looks like it's blocking lispy-rust.
It was fixed by ; do you still see this issue present in nightly?


Question: <ins> error: prefix `f` is unknown --> $DIR/dont-ice-on-invalid-lifetime-in-macro-definition.rs:5:17 | LL |             e::<f'g> |                 ^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: consider inserting whitespace here | LL |             e::<f 'g> |                  + error: aborting due to 1 previous error </ins>

<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
:thinking: this bisects to cc
very plausible :+1:
Reduced


Question: <ins> error: `_x @` is not allowed in a tuple --> $DIR/issue-72574-1.rs:4:14 | LL |         (_a, _x @ ..) => {} |              ^^^^^^^ this is only allowed in slice patterns | = help: remove this and bind each tuple field independently help: if you don't need to use the contents of _x, discard the tuple's remaining fields | LL |         (_a, ..) => {} |              ^^ error: aborting due to previous error </ins>

and I are working on diagnostics for the rest idiom in slice patterns () and came across this issue when an attempt is made to use it in tuples and tuple structs. IIUC, this is allowed: and this is not allowed (note the addition of ): The error messages for the tuple and tuple struct cases include the following incorrect information: This should state that the id binding to rest is not allowed. patterns are allowed. is only allowed in slice patterns, not in tuple or tuple struct patterns. This should state that the idiom is only allowed in slice patterns. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
appears to be the site of the check: This method is called:
Perhaps it's worth supporting "tuple slicing" pattern too in Rust:
that would implicitly create a tuple for (or a slice?). I don't think it'd be a good addition. We already support , which is much more useful in my eyes.
That syntax is meant to produce a shorter tuple xs with the omission of the first item of the tuple. lf you think it's an useless idea then let's ignore it :)
claim


Question: <ins> #![feature(half_open_range_patterns)] macro_rules! funny { ($a:expr, $b:ident) => { match [1, 2] { [$a, $b] => {} } }; } fn main() { funny!(a, a); //~^ ERROR cannot find value `a` in this scope //~| ERROR arbitrary expressions aren't allowed in patterns } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.57.0 ( 2021-11-29) running on x8664-unknown-linux-gnu note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
reduced:
Minimized this a tiny bit further, and I have a detailed explanation why this occurs: So this bug first starts going wrong in late resolution. Specifically, , we define the as a binding when we see the second element (ident subpattern) of the slice pattern, and then bind it later when we walk thru the (expression!) in the first slice pattern element. Essentially, since we treat as being defined here: and then resolve that as the path for we reach a situation where we expect a variable to have been defined before it has been lowered in HIR, which leads to the ICE later on, since we expect to have lowered that path element.
Wonder how difficult it would be to make have subpatterns instead of subexpressions... edit: wouldn't help, see below..
Actually, I don't think fixing this just for ranges is sufficient. I can reproduce this same issue with this: Maybe I can just delay this panic as a span bug, since we're always gonna error out anyways. I think I would ideally like to fix this by making sure we separate bindings in patterns from affecting resolution for expressions in patterns. edit: Ended up fixing it the right way.
claim


Question: <ins> //@ edition: 2021 //@ check-pass //@ revisions: current next //@ ignore-compare-mode-next-solver (explicit revisions) //@[next] compile-flags: -Znext-solver #![feature(async_closure)] use std::future::Future; use std::any::Any; struct Struct; impl Struct { fn method(&self) {} } fn fake_async_closure<F, Fut>(_: F) where F: Fn(Struct) -> Fut, Fut: Future<Output = ()>, {} fn main() { fake_async_closure(async |s| { s.method(); }) } </ins>

When using async closures, rust since around 1.80 fails to infer parameter type in most scenarios. I expected to see this happen: All options used to work in past versions of rust Instead, this happened: Without explicit type hint it fails It used to work in the past, around 1.79
We don't typically mark nightly features with labels, so I'm removing those. Are you certain this regressed in 1.80? This should have regressed in , when I reimplemented async closures completely.
I am not 100% sure when it happened. I used to work with 1.7x a couple of months ago. Then I left my project for a moment. When I came back, after updating to 1.81 it no longer works. IIRC before leaving it was around 1.79, but I'm not sure.
This limitation to async closure signature inference has to do with the fact that the combinators you're using (e.g. ) take regular trait bounds. Is there a particular reason you're using async closures here? They're really not gaining you anything other than a dependency on the nightly compiler.
I posted a minimal example, indeed async does not make much sense here, but in project I work on it does. As a workaround I've just annotated parameters with original types, but I still believe this is a bug.
This indeed regressed in .
While the problem from first message in issue seems to be fixed, there are still cases when this fails. One of examples is when using instead of , when closure is expected to return : Should I open new issue, or this one will be reopened?
Please open a new issue, since it's likely a different root cause


Question: let gen_sig = substs.as_generator().poly_sig(); <del> // (1) Feels icky to skip the binder here, but OTOH we know // that the self-type is an generator type and hence is </del> <ins> // NOTE: The self-type is a generator type and hence is </ins> // in fact unparameterized (or at least does not reference any <del> // regions bound in the obligation). Still probably some // refactoring could make this nicer. </del> <ins> // regions bound in the obligation). let self_ty = obligation .predicate .self_ty() .no_bound_vars() .expect("unboxed closure type should not capture bound vars from the predicate"); </ins> let trait_ref = super::util::generator_trait_ref_and_outputs( self.tcx(), obligation.predicate.def_id(), <del> obligation.predicate.skip_binder().self_ty(), // (1) </del> <ins> self_ty, </ins> gen_sig, ) .map_bound(|(trait_ref, ..)| trait_ref);

An there actually does panic for the test. I only moved this code between the files, the same comment and code pattern exists as well for normal closures: Originally posted by in
I couldn't repro this failure, maybe was doing instead of ? The ordering is important here.
I believe I did, yes.


Question: LL | fn is_unwindsafe(_: impl std::panic::UnwindSafe) {} |                          ^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `is_unwindsafe` <del> error[E0277]: the type `&mut (dyn Any + 'static)` may not be safely transferred across an unwind boundary --> $DIR/async-is-unwindsafe.rs:12:5 | LL |        is_unwindsafe(async { |   _____^_____________- |  |_____| | || LL | || LL | || LL | ||         use std::ptr::null; ...  || LL | ||         drop(cx_ref); LL | ||     }); | ||_____-^ `&mut (dyn Any + 'static)` may not be safely transferred across an unwind boundary |  |_____| |        within this `{async block@$DIR/async-is-unwindsafe.rs:12:19: 30:6}` | = help: within `{async block@$DIR/async-is-unwindsafe.rs:12:19: 30:6}`, the trait `UnwindSafe` is not implemented for `&mut (dyn Any + 'static)`, which is required by `{async block@$DIR/async-is-unwindsafe.rs:12:19: 30:6}: UnwindSafe` note: future does not implement `UnwindSafe` as this value is used across an await --> $DIR/async-is-unwindsafe.rs:26:18 | LL |         let mut cx = Context::from_waker(&waker); |             ------ has type `Context<'_>` which does not implement `UnwindSafe` ... LL |         async {}.await; // this needs an inner await point |                  ^^^^^ await occurs here, with `mut cx` maybe used later note: required by a bound in `is_unwindsafe` --> $DIR/async-is-unwindsafe.rs:3:26 | LL | fn is_unwindsafe(_: impl std::panic::UnwindSafe) {} |                          ^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `is_unwindsafe` error: aborting due to 2 previous errors </del> <ins> error: aborting due to 1 previous error </ins> For more information about this error, try `rustc --explain E0277`.

https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.


Question: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>

The AVR-Rust post continues to track AVR-LLVM, which is tracking upstream LLVM. That means we are running into changes from the future LLVM 4.0. I figured we could open up this issue now to track the changes required to stay compatible. This is the current list of upgrade hazards. Note that some of the text may be nonsensical as I don't truly grok all the internals of LLVM so some changes are wild stabs in the dark. It's also possible that some failed fix for earlier problems actually caused later problems: [x] DIDescriptorFlags became a real C++ enum and not a bitset () [x] An EH personality is required for every function that can unwind () [x] pass changed header and constructor name () [x] changed API () [x] Bitcode/ReaderWriter.h has been renamed / API changed () () [x] changed API () [x] changed API () [x] prefers over () [x] string type changes () [x] is not guaranteed to be null terminated () [x] changed return types () [x] Archive support changed error handling types () [x] Teach Rust about an LLVM 4.0 API change for creating debug info for global variables () [x] Check all errors in LLVMRustArchiveIterator API () [x] Upgrade emscripten (kripken/emscripten-fastcomp, kripken/emscripten-fastcomp-clang) [x] Alignment now represented with 32 bits instead of 64 () [x] API changed again () [x] now takes an instead of a and () [x] Symbol lookup error when linking dylibs () [x] Undefined behavior in tests () [x] Unoptimised builds of compilerbuiltins on ARM have references to () A WIP PR that performs the upgrade! Some issues whose resolution is believed to be blocked on LLVM 4.0: [ ]
Next time we do this upgrade we'll need emscripten to do it to. It would be good if we could pull in a working llvm wasm backend in the same upgrade, but that may not be ready before the end of the year.
For the record, I am also working with a fork of LLVM that is tracking upstream (not AVR-LLVM but similar in spirit) and am starting to work on this now.


Question: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>

I'm looking through the AVR-Rust commits and I'd love to coordinate --- feel free to ping me on IRC () or via mail!
Note that there is a regression reported against llvm 4.0 regarding the powi intrinsic on armhf targets: I'm explicitly mentioning this here, because there were previously problems with it, see and related issues. Also cc rust-lang-nursery/compiler-builtins, an issue about the same problem in the compiler-rt rust port.
To clarify what I think the is referring to (correct me if I'm wrong) In LLVM 3.9 and before, the calling convention LLVM used with the powidf2 and powisf2 intrinsics was basically the C calling convention In LLVM 4.0, the backend was corrected to expect these intrinsics to have the aapcs calling convention One person that aapcs is expected for powis2f and powid2f, while another a claiming that the normal C calling convention should be used. So it seems that if the LLVM change is not reverted (expected powisf2 to be aapcs) then we need to update our definition. This is going to be a huge PITA for supporting multiple LLVM versions as well. We need to select the calling convention depending on the LLVM version as well...
Any objections to doing that coordination here on GitHub, or on one of our forks?
I don't have strong preferences for the communication channel.
should address what is listed as API changes" above (the core of the change is in how attributes are represented).
I would prefer to upstream LLVM 4.0 compatibility patches sooner rather than later. That includes my own work obviously, but I'm also looking at the commits I cherry-picked from AVR-Rust. In particular, looks like a reasonable simplification even independent of LLVM 4.0 compatibility, and looks like a nice little self-contained fix. Could you create PRs for those? (If you don't have the time but are otherwise fine with upstreaming, I'd be happy to manage that, giving proper credit of course.)
Absolutely! I wasn't really sure how much we could expect LLVM 4 to change as it goes towards stable / how much churn the Rust maintainers would want to put up with. I'll get those pulled out and submitted soon. I think I'm also starting to understand some of the silly error handling that the new LLVM does.


Question: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>

Awesome, thanks in advance!
BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of
Does anyone have ETA? I'd like to know when I can use AVR. :)
You should follow along at avr-rust/rust for the AVR-specific issues. Upgrading to LLVM 4 will not magically yield AVR support.
Ok, thank you!
I've created for the API change.
I've also created for another debug info API change.
After putting all of those patches on top of master, was successfully built. I got several undefined references, most likely due to my local LLVM setup.
I think the next step after all those patches land is to allow LLVM 4.0 in the configure/rustbuild scripts and then actually update the submodule.
We'll also need to fix that AAPCS bug first, I just noticed it
Don't forget : I think that means that the Rust fork of LLVM is following the Emscripten fork of LLVM, thus Emscripten needs to upgrade to LLVM 4.0 / master before Rust can.
And I'm hoping to supersede it with
I just ran into which changed the alignment from u64 to u32. Will think about a proper fix later, unless someone beats me to it (but should merge first to avoid further conflicts).
And it says So, that will be "exciting".
Is there much left blocking an upgrade?
This: Has to be done too but I don't know if it's currently being worked on. Any info on that ^?
No nobody is actively working on an emscripten upgrade. Since even when that is done it will probably take a lot of work to land an LLVM upgrade, there's probably more we can do to prepare. Once we decide we want to do it, somebody can prepare a patch to throw at the bots. It seems likely stuff will not work and it will be a slog to fix it all, which will give us time. We don't need emcc to generate wasm stds, just a fairly small patch on our LLVM branch that will hopefully port without much difficulty. So if somebody feels motivated, it's not too soon to start going after it. As to the emscripten upgrade, we should at least let know that we're starting to think seriously about doing the upgrade, and need emscripten to upgrade LLVM too.


Question: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>

It seems like that could be a big effort. Another alternative is to use the LLVM wasm backend, but I still have not heard that it is generally usable yet. cc
I can look into the effort needed to update emscripten's fastcomp LLVM version, but I need to know a commit to aim for. Sounds like the goal here is 4.0, which hasn't released yet, so I guess I have to wait on that?
So far as AVR is concerned, any commit within the last month will do. There will likely be a few more months until 4.0 is actually tagged (every ~6 months a new release is made). It is quite common for projects to track LLVM master, which I'm personally a fan of.
But is it common to release snapshots from LLVM master? When LLVM itself only releases every 6 months, it seems incongruous for Rust to pick arbitrary snapshots in its 6-week release cycle.
LLVM 4.0 will branch in a week and the final release will happen in late feburary (schedule says 21st for final tag, but this is flexible IIRC).
From the llvm-dev mailing list:
branch has happened
An update on the "powidf2 / powisf2 calling convention changed" situation: The regression has been fixed on llvm master () however from what I can tell the fixes are not yet in the 4.0 branch, although the fix may be backported ().
I've started working on updating emscripten kripken/emscripten-fastcomp kripken/emscripten-fastcomp-clang I've also created a new bug requesting that the regression fix be merged into 4.0 .
says the emcc LLVM upgrade is ready to go. or are we prepared to begin the Rust LLVM upgrade? I think what needs to happen is to submit the Rust PR and start throwing it against the bots. Once it looks like that is close to landing then we'll have to coordinate both project's upgrades to minimize the breakage window where rustc and emcc have different backends. I'm not sure how best to do that - we might just try to upgrade as simultaneously as possible and accept up to a few days of breakage, or we might ask emscripten to stage their build such that they can swap their incoming branch right after we land to master.


Question: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>

needs to know the exact LLVM commit we're moving to as well, and that will become clear once the PR starts working through the queue. The stars are aligning. Let's make this happen. Thanks for doing the fastcomp upgrade.
We are not fully compatible with LLVM 4.0. I have heard from at least one person (on IRC) that building against stock LLVM 4.0 (RC) does not work. I haven't personally inspected all failures, but there's at least two things still missing: (and possibly ). It shouldn't be a conceptually difficult patch to apply the equivalent changes to rustc, but possibly a big diff. I haven't digested the implications yet, but it might be a relatively simple change localized to the function in that currently calls .
The fix has been merged into the 4.0 release (). I'm going to try and build Rust against stock LLVM 4.0 and figure out what needs modifying.
On top of what mentioned: now takes an instead of a and ()
I've got a half-baked patch to use the new signature for I'm not familiar enough with Rust internals to finish it off. I ran into a problem in as it is given a but in order to use we need a . We need to call in order to build an instance of .
I've opened for the change that mentioned. I've also opened for the 32-bit alignment change. I believe that is the only thing we need to update aside from these two PRs in order to get the compiler to successfully be built with LLVM 4.0.
So to summarize where we are with LLVM 4 (correct me if I'm wrong): 4.0 will be released in about 1 week (2/21). are no known issues with supporting LLVM 4.0, but there are probably issues that will be discovered once we try to use it in nightlies. runs on in-tree LLVM + LLVM 3.7 (so PRs haven't actually been tested on LLVM 4.0 yet). support LLVM back to ~3.6(?


Question: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>

)~ 3.7 and will continue to support it until either: a. It's so old that it can be removed without bothering package maintainers b. We need at least version X in order to fix an important bug c. The API is so different from version Y that it's a huge pain to support will open a PR to update the submodule shortly after release but it will take a month to land due to: a. Waiting for emscripten ( -) b. Bugs in upstream c. Missed LLVM API changes d. Making bors happy e. All of the above
Thanks for the summary The only correction I'd make is that in your point (4) you can s/3.6/3.7/, but otherwise it's accurate :) If you'd like to start preparing a PR to update to LLVM 4.0 I don't think we need to block waiting for LLVM itself to release 4.0. Currently only one Travis builder runs on each PR but we could temporarily allow more builders running on an LLVM 4.0 PR to start weeding out bugs before it hits
I gave it a go but I don't think my git-fu (or patience) is strong enough to handle a big merge like this. What I can do is try to run rustc with upstream LLVM and file/fix issues as I find them. There is at least one issue remaining as of (details to come).
Whoever ends up doing the LLVM upgrade, please also upgrade the compiler-rt submodule so that the sanitizer related LLVM passes don't diverge from what the sanitizer runtimes expect.
In fact, if you upgrade before the release, they usually mention your project in the release notes. :)
So whats the next issue(s) to subscribe to in the race-to-AVR? :)
As says on , we can integrate the latest Rust master into the avr-rust compiler. After that, we can spend some time getting compiling for AVR. Once that is working, we could then start looking into upstreaming the AVR target to Rust.
AVR-specific issues can be raised / tracked in For example, there are two that I'm aware of right now:
has been closed, so that can be checked off in the top post.


Question: .map(|res| (res, extra_fragment.clone())), type_ns: match self.resolve( path_str, <ins> disambiguator, </ins> TypeNS, &current_item, base_node,

I tried to document this code: I expected to see this happen: charstd::char` points to module page of char type points to char primitive page Instead, this happened: type points to module page of char :
I think the problem is that modules are in the type namespace, so is doing exactly what you are asking it for (the module, since it has higher priority). Since the built-in types scope is the lowest precedence, perhaps there needs to be a way to access it directly? Maybe something like or ? Or maybe should skip over modules, and keep looking deeper in the scope hierarchy? (cc )
Oh hmm I see what you mean. There are : Types, values, and macros. Since modules and types are in the same namespace, it uses the first one it finds. Maybe we could work around this by first resolving in an empty module (so it has nothing in scope), then only falling back to the current scope if we don't find something there?
I'm surprised this hasn't caused trouble before now. Does the root of never use the primitive?
I don't know how it works, but the resolver is smart enough to know that in a type context won't match a module (like , the won't match a module named "char". Maybe it has something to do with late-resolution  which has a to give it some context?
Adding that would be more of area ... I can give it a shot though.
It looks like doesn't even return a resolution and only records it for later use ... I'm going to go with the empty module workaround and we can fix it later if it turns out to cause issues.
The double resolve seems hacky. We could probably make type@ specifically not resolve to a module, perhaps? Also, note that modules are in all namespaces
How would that work? We could skip any module resolutions, but since modules have precedence over types I don't know how we'd get the primitive type to resolve afterwards.
Oh hold on we have a function already. We can look at directly.
This doesn't have anything to do with primitives, this has to do with glob imports vs non-glob imports. You can get the same issue with the following:
This also doesn't have to do with modules being "resolved first" or anything. Things that are non-glob in-scope are resolved first.


Question: .map(|res| (res, extra_fragment.clone())), type_ns: match self.resolve( path_str, <ins> disambiguator, </ins> TypeNS, &current_item, base_node,

Actually, my bad: This does have to do with primitives in the sense that primitives are the only thing that still work when shadowed because of some special code in checking the primitive tables. I think when the string matches one of the primitive table entries for TypeNS lookups that were explicitly annotated with type@ and resolve to a module we can hack this in. In the future we might want to tighten up this code so that e.g. can't resolve to an enum, etc.
do you mind if I fix at the same time and resolve primitives even before modules? That seems like the less surprising behavior to me, the module can still be disambiguated with .
I'm a bit wary of doing this because having the char module in scope is not a common situation, and it will get weirder for people who have a different char module. I think we should resolve to whatever is in scope, but if is explicitly mentioned we can then force resolve to the primitive.


Question: assert_eq!(find_best_match_for_name(&input, Symbol::intern("1111111111"), None), None); <del> let input = vec![Symbol::intern("aAAA")]; </del> <ins> let input = vec![Symbol::intern("AAAA")]; </ins> assert_eq!( <del> find_best_match_for_name(&input, Symbol::intern("AAAA"), None), Some(Symbol::intern("aAAA")) </del> <ins> find_best_match_for_name(&input, Symbol::intern("aaaa"), None), Some(Symbol::intern("AAAA")) </ins> ); let input = vec![Symbol::intern("AAAA")]; <del> // Returns None because `lev_distance > max_dist / 3` assert_eq!(find_best_match_for_name(&input, Symbol::intern("aaaa"), None), None); let input = vec![Symbol::intern("AAAA")]; </del> assert_eq!( find_best_match_for_name(&input, Symbol::intern("aaaa"), Some(4)), Some(Symbol::intern("AAAA"))

Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note suggesting the variant with the same name (but different case):
label +C-enhancement +D-newcomer-roadblock
This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.
im working on this Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.
Okay, judging by , this is explicitly not supposed to work. shrug emoji Edit: Okay, maybe that test case didn't really care. The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with afaict.


Question: let mut _4: &mut [T];                // in scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:6 scope 1 { debug self => _4;                // in scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL <ins> let mut _5: &mut [T];            // in scope 1 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15 </ins> } bb0: {

Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.


Question: let prog = time(sess.time_passes(), "running linker", || cmd.output()); match prog { Ok(prog) => { <ins> fn escape_string(s: &[u8]) -> String { str::from_utf8(s).map(|s| s.to_owned()) .unwrap_or_else(|_| { let mut x = "Non-UTF-8 output: ".to_string(); x.extend(s.iter() .flat_map(|&b| ascii::escape_default(b)) .map(|b| char::from_u32(b as u32).unwrap())); x }) } </ins> if !prog.status.success() { sess.err(&format!("linking with `{}` failed: {}", pname,

Compiler crashes while compiling using Cargo. Cargo version: cargo 0.6.0-nightly ( 2015-10-17) rustc version: 1.3.0
It looks like this comes from the linker producing output (normal or error) that is not valid UTF-8. Fixing this in any other way than just using a lossy conversion is going to be really painful because it goes through the error logging infrastructure, which all works with s. That's certainly not ideal, because it would be best to relay other programs' messages to the user unchanged, but it's probably the only realistic way to handle this in the near future.
Just dump the bytes as hexadecimal? I am not sure what is going on here.
My first thought was that the path was probably not UTF-8, but because of the way cargo invokes it that crashes rustc long before it tries to link anything, so that can't be it. I'm not sure why else the message would be non-UTF-8. (I can't reproduce the ICE on that crate (I just get a normal link error), but I can reproduce the ICE by constructing a situation where the linker prints non-UTF-8 messages.) But yeah, some kind of lossy conversion with hex escapes is probably the way to go. I'm not aware of an existing function to do that.
Actually, mapping with is probably good enough.
foo'ncollect2: error: ld returned 1 exit statusn` Not great, but not an ICE and probably good enough until we have a dedicated function to do this sort of thing since this should be a very rare error.


Question: <del> Subproject commit 097d8908339e20435078233a55a1a3335fe7c2eb </del> <ins> Subproject commit 9ed6f96f2ff85753c5a6ac290ee88ecb2831ab2e </ins>

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!
Sure, I can look at this one.
Thanks for merging ! If I'm reading things right, I think I need a new crater release of it so I can update ? If so, can you please make one of those?


Question: |                    +++ error[E0562]: `impl Trait` is not allowed in `fn` pointer parameters <del> --> $DIR/generics.rs:17:43 </del> <ins> --> $DIR/generics.rs:18:43 </ins> | LL |     f2: extern "C-cmse-nonsecure-call" fn(impl Copy, u32, u32, u32) -> u64, |                                           ^^^^^^^^^

<!-- ICE: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc


Question: fn f<F>(f: F) where F: Fn(isize) { f(10) } <del> fn main() { f(|i| { assert_eq!(i , 10) }) } </del> <ins> fn main() { f(|i| { assert_eq!(i, 10) }) } </ins>

proc-macro derive panicked All of the 62 regressions are due to old versions of having an assert expecting instead of . So this is again a consequence of whitespace changes in pretty-printing (). I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.
Fixed in
Just FYI, we discussed this in the meeting. We felt like the action here was appropriate -- while in general we do not guarantee stability of pretty printing, it makes sense to be judicious, and in this particular case not having a leading space before just looks better anyway.


Question: /// Allows the user of associated type bounds. (active, associated_type_bounds, "1.34.0", Some(52662), None), <del> /// Allows calling constructor functions in `const fn`. (active, const_constructor, "1.37.0", Some(61456), None), </del> /// Allows `if/while p && let q = r && ...` chains. (active, let_chains, "1.37.0", Some(53667), None),

The feature allows calling any expression of a tuple-like constructor in a : cc
Implemented on 2019-06-07 by in which was reviewed by
Is there anything else needs to be done to resolve this issue?
FCP and stabilization pull request.
Do you think you have time to write a report (e.g. in the style of ) and amend the reference after?
I propose that we stabilize . Tracking issue: Version target: 1.40 (2019-11-05 =beta, 2019-12-19 =stable). Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called : Consistency with other . This should also ensure that constructors implement traits and can be coerced to function pointers, if they are introduced. - Tests various syntactic forms, use in both and items, and constructors in both the current and extern crates. The case in should also get a test.
Thanks! Could you embed this report in a PR with the aforementioned test there as well? I'll FCP that PR.


Question: /// Allows the user of associated type bounds. (active, associated_type_bounds, "1.34.0", Some(52662), None), <del> /// Allows calling constructor functions in `const fn`. (active, const_constructor, "1.37.0", Some(61456), None), </del> /// Allows `if/while p && let q = r && ...` chains. (active, let_chains, "1.37.0", Some(53667), None),

When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per


Question: source_file } <del> } </del> <ins> }; Ok(lrc_sf) </ins> } /// Allocates a new SourceFile representing a source file from an external

I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened


Question: // aux-build:lint_stability.rs // aux-build:inherited_stability.rs <del> #![feature(globs)] </del> <ins> #![feature(globs, phase)] </ins> #![deny(unstable)] #![deny(deprecated)] #![deny(experimental)] #![allow(dead_code)] mod cross_crate { <ins> #[phase(plugin, link)] </ins> extern crate lint_stability; use self::lint_stability::*;

The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc


Question: <ins> // aux-build: similar-unstable-method.rs extern crate similar_unstable_method; fn main() { // FIXME: this function should not suggest the `foo` function. similar_unstable_method::foo1(); //~^ ERROR cannot find function `foo1` in crate `similar_unstable_method` [E0425] let foo = similar_unstable_method::Foo; foo.foo1(); //~^ ERROR no method named `foo1` found for struct `Foo` in the current scope [E0599] } </ins>

It would be more helpful to suggest the method for the typo rather than a nightly-only symbol which isn't actually available. the suggestion doesn't work. method is actually available on a . method has been stable since 1.0.0. had trouble noticing the difference between and and could have used the compiler's help. No response Reproduced with 1.68.0 stable and 1.70 nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { *return; //~ ERROR type `!` cannot be dereferenced } </ins>

Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

This effectively means you can't compile for these targets.
This may have been caused by the i128 PR ( ). No LLVM assertion is raised if I compile with , which removes the i128 stuff. We could try to fix this or we could cfg away the i128 stuff for the nvptx targets in the meantine. The LLVM assertions render the NVPTX backend unusable in the nightlies. cc Have you seen any LLVM assertion like the ones above while working on implementing i128? cc cfg?
no, I can't remember seeing such an assertion. It seems to be in PTX related code. but its very likely that i128 broke some of the non tier1 platforms. You can only tell whether they break once they actually do :/ Can you try to generate a minimum reproducible example? Then we might know more...
Seems like the msp430 target broke too: with Using works fine. cc
Examples
msp430 EABI doesn't specify how to return 128 bit values, and LLVM does not support them on msp430, so I don't see an easy fix for this.
These are tier 3 platforms, so basically anything goes IMO in terms of language guarantees. If they don't support i128 at a fundamental level then it seems like if we want them to compile we'll have to cfg out support.
I'm trying to understand this better: If the ABI does not specify how 128-bit values are passed/returned, does that mean that the architecture doesn't support 128-bit values at the fundamental level?Do all the ABIs of the all the other platform 2 targets (x86, ARM, MIPS, PowerPC, SystemZ) specify how 128-bit values are returned?(What about wasm and Do those even have an ABI? How does the 128-bit stuff even works there?) I'm wondering if we should: Add a field to target specifications. For targets that don't support i128 at the fundamental level.Or, maybe add Cargo feature to to cfg away the i128 stuff.Or unilateraly cfg away i128 in core for nvptx and msp430. I personally don't like either option. To me this seems like a limitation in what LLVM can do today but that can be fixed in the future.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Also, if we had pure MIR rlibs this wouldn't be a problem at all because the i128 stuff would never be passed to LLVM if it wasn't being used by the final application. To sum it up, I'm not sure what to do here ...
Right now on MSP430 values from the functions are returned using 4 16bit registers r12-r15. So in total you can return only 64 bits of data. There is an exception though, for returning large structs, the data is placed on the stack and reference is placed in the registers. So I guess it will be possible to bodge some hack that will treat i128 like a struct, but I don't know if anyone tried to implement 128 bit values on 16bit cpu, so it will be a new territory and potentially a lot of work for a feature that may not be useful at all on a small MCU.
yeah, but if LLVM can generate code for a function that returns then it should be able to use the same trick to return an . It's just that noboby has taught it how to do that. (i128 ops are totally different though but at least LLVM should emit intrinsics instead of raising assertions) How about on 8-bit AVR?
AFAIK, if Rust code calls Rust code, the ABI is totally irrelevant. We can do whatever we want. However, it starts getting a problem once we start talking to non Rust places, e.g. for FFI, or when LLVM emits a call to i128 intrinsics. For FFI we might want to end up forbidding fn's and structs that have i128 for targets where i128 is not specified by the convention or buggy in LLVM. With intrinsics, there has been major pain on Windows with because LLVM assumed a different ABI than what Rust provided with . It was "fixed" by introducing the "unadjusted" ABI, and it might work for nvptx64/msp430 as well, but it can just as well still cause an assertion failure. Real need for is only for platforms that want to cryptographic libraries, or maybe even std, as those two places might want to use . The higher stages of the compiler itself require i128 support as well, so if your platform wants to be a host platform for rustc, you'll need to support i128.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

I'm okay with any of the three options (flag in , feature for , only setting it for those two platforms) for these platforms.
No. No. Namely the x64 windows ABI is kinda fuzzy about how i128 values are handled so carefully reading it we arrived at a conclusion that they ought to be handled the same way as regular 16-byte structs on 64 bit window platforms. A target cannot not support i128 at a fundamental level the same way a target cannot not support writing turing complete software. IMO what we should do here is to fudge the ABIs somewhat to take and return arguments via pointers (or the same way would be handled) on these targets. C ABI will be more complex; as already said there will always be at least one user of the C ABI with i128 arguments and stuff – LLVM with their intrinsics. The question here is how does LLVM lower to the intrinsics on these targets. If the backend does not lower and asserts for whatever reason, the targets have what’s essentially a broken backend implementation. Which seems to be broken for at least NVPTX () in exactly the place where I’d expect it to be broken if it was broken: That being said, since the C compilers do not support i128 for those targets, the actual interoperation does not matter whatsoever. All that’s really needs to be fixed is LLVM’s lowering of instructions to intrinsics using whatever ABI that works, even if its passing in arguments and taking return value via pointers. I, myself, am very strongly against splitting the language feature sets depending on the target.
How do we break the stalemate? If we submitted changes upstream for each of the smaller targets w/o support for i128 (providing indirection like large structs) it seems like it would meet resistance. As says, it's likely not considered useful since there's many targets without any native registers or support for such large values. But we also also have reluctance to limit this type to only appropriate targets. Does the "vision for 2017 cycle" provide any guidance? Does "provide a more seamless FFI story" help push us in one direction or the other?
regardless whether useful or not, we do need to support i128 on all targets, otherwise people will start using libraries that provide it across platforms.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Even if it needs to be "virtualized" in some way, and not wholly put into registers. In the worst case we'd have to provide some translation before passing things to LLVM, but it will affect things like alignment and generally looks like an ugly workaround. About FFI, I guess we can't really provide any FFI for i128 on targets where there is no C support for it, as generally the calling conventions only specify things that are part of C.
None of the targets Rust supports have native support for 128-bit integers, other than the fact that some can implement unchecked division and multiplication involving 128-bit integer operand with a single insn. Why? All that needs to be done here is to have the backends fixed. LLVM is supposed to be agnostic over bitwidth of integer, however useful or not somebody on the internet perceives such functionality to be. In other words, its a backend bug. So, its probably pretty clear that all it takes is to write a patch to fix bugs in these backends wrt operations on large values. I have no knowledge of these targets, am not familiar with the backends and haven’t the hardware to test any fixes on, so these patches will have to be written by somebody else. Late answer, but I’ve noticed this only now. This observation is wrong in multiple places. Firstly, (a.k.a. returning via pointer) is not a hack. Neither is it an exception. That’s what pretty much every single ABI¹ out there does for values that do not fit into register(s). It is most likely true that MSP430 ABI does not specify what to do with PODs this large, so it falls on us to pick whatever. ¹: For a less obscure example, x64 ABI used by code targetting Windows mandates to be used for any non-vector values over 64 bit in size, even though they could be fit it into registers. SysV ABI starts returning stuff via after some size threshold as well.
The MSP430 ABI specifies that aggregates larger than 32 bits are passed and returned via pointer. The backend just doesn't implement sret correctly yet (and in fact is implemented targeting an old and outdated ABI in any case). I'm working on fixing this in LLVM.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

I'd bet that similar problems explain the NVPTX problems but I know nothing about that platform so I can't say that for sure.
I also agree that fixing backend is the right thing to do. I just think that it is not that easy as you say it is. MSP430 is the only 16bit architecture in LLVM, and this creates some trouble by itself. Good to know that someone is working on this.
does that LLVM patch really fix NVPTX as well?
No, it doesn't. this should be reopened for NVPTX.
BTW, thanks to for fixing this in LLVM upstream.
Triage: MSP430 has been fixed. No change in the NVPTX backend.
What needs to be done to get NVPTX working again?
You can see the patch I did for the MSP430 above - if it's the same problem you basically just have to add sret (structure return) support to the LLVM backend. I don't know anything about NVPTX but I'd bet it's pretty much the same procedure as what I did for the MSP.
Note that you can use the NVPTX backend today with the nightly compiler if you use a fork of the libcore crate that doesn't include 128 bit integers. Instructions .
I have some progress on the issue. First, I tried a hacky workaround with replacing with in arguments and return values with a custom FunctionPass. Can be transformed to: And compiled to PTX with vanilla LLVM (): Then, I made less hacky workaround patching LLVM NVPTX backend so it became possible to compile the code with without additional passes. Is compiled with patched to pretty much valid and working PTX assembly ;) But another related problems appears. When instead of: I write: I receive an error: And similar error when I try to compile : Does anybody have any suggestions about the problems? Looks like PTX doesn't have an instructions for the functions, and LLVM can't expand them.
Looks like the expansion from i128 to i64 is going OK but the i64 sdiv/mulo instructions aren't properly implemented. Not sure why that might be... it kind of looks like it's trying to assign the address of a library call and that's not working. Possibly the way you implemented the i128 expansion prevented a subsequent i64 expansion from running but I can't tell without seeing the code.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Run llc with -print-before-all and/or -print-machineinstrs to see where things diverge from what you expect. Look up in your platform ABI what the right action to take for 64-bit divides actually is. Post a link to your changes and someone may be able to take a look at them and see the problem.
Traditionally, in LLVM, is implemented by the library. However, its disabled on most platforms. Not sure why, but is written in C so they probably only can support i128 on platforms where they also provide C support, and clang's C support for i128 is right now very limited. Rust however the function, inside the crate (that is a wrapper for compiler-rt). There are good chances it works already!
It has pretty expected output before and after each pass. I think more interesting would be output with , but I don't really understand it. of the next commands: I tried to make changes over LLVM as minimal as possible: . I'm quite confused about and . Should they be compiled for target or host? If we can build at least for NVPTX, then can we just link against it? It still require some more changes for LLVM to be able to threat libcalls as normal calls. But then, all we would need is to link against . This blocked by but might be solved with my experimental .
For the target. At least its that way on other platforms. What is LLVM doing on 32 bit NVPTX when it encounters a 64 bit operation? On normal targets, this is one of the places compiler-rt gets used. Or idk, to cast a float to an int and back.
by the way, I didn't congratulate you yet for your progress. Really great work, loving it!
I'd like to see this move forward, so I'll summarize the above. Please correct me if I'm wrong: This issue was fixed for the MSP430 backend by submitting a patch to LLVM. worked on a patch to do the same for NVPTX, but it was not submitted to LLVM. I imagine that since that was a year ago, the patch will need some work to bring it up to date. Is this problem still happening with more recent builds? Perhaps it's been fixed by upstream in the meantime.


Question: <del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

If it is still a problem, what would have to be done to fix it?
Well, my patch related to landed in LLVM about year ago. Now we can compile simple examples without any problems: with which produces the PTX assembly: And as for me, the issue can be closed. I was able to compile a kernel from  with latest nightly. So the hack with custom is obsolete now.


Question: use rustc::mir::{Mir, Place}; use rustc::mir::{Projection, ProjectionElem}; use rustc::ty::{self, TyCtxt}; <ins> use std::cmp::max; </ins> pub(super) fn places_conflict<'gcx, 'tcx>( tcx: TyCtxt<'_, 'gcx, 'tcx>,

Minimal example: This will complain about multiple mutable borrows, even though it should be valid.
Noted in (but may deserve a separate bug report?). (FYI, slice patterns are unstable for a reason; they're pretty buggy at the moment).
should be closed after MIR borrowck will be by default


Question: rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done

We currently emit vec growth glue, but it is called using the push/pop mechanism (e.g. of transcallglue). In reality, the only call site for this glue is generated when translating vec append statements, so it really is user-level glue and need not adhere to the "worst-case glue-call args" max argument count. The fact that we don't do this costs us one extra word of worst-case glue-call args at the moment (7 words instead of the 6 we'd need otherwise). This is a relatively minor issue, but now noted.
WONTFIX (not required for bootstrapping)


Question: rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done

Currently, pointers stored on the stack aren't word-aligned. This is a critical issue because it causes stack growth to fail most of the time.
Commit disables task growth for now until this is fixed.
WONTFIX (moot point given disabled stack growth)


Question: rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done

u32(1234) should be 1234u32, and handled in the lexer The former is chatty and confuses the issue with runtime calls / casts (the latter of which should be shifted to 'as' casts anyway).
Switch machine-type lexemes to use suffixes. Remove support for foo(bar) as a cast notation. Closed by .


Question: <ins> warning: trait-associated function `from_iter` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-generic.rs:28:5 | LL |     Generic::from_iter(1); |     ^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `<Generic<_, _> as MyFromIter>::from_iter` | note: the lint level is defined here --> $DIR/future-prelude-collision-generic.rs:5:9 | LL | #![warn(rust_2021_prelude_collisions)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see issue #85684 <https://github.com/rust-lang/rust/issues/85684> warning: trait-associated function `from_iter` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-generic.rs:31:5 | LL |     Generic::<i32, i32>::from_iter(1); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `<Generic::<i32, i32> as MyFromIter>::from_iter` | = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see issue #85684 <https://github.com/rust-lang/rust/issues/85684> warning: trait-associated function `from_iter` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-generic.rs:34:5 | LL |     Generic::<_, _>::from_iter(1); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `<Generic::<_, _> as MyFromIter>::from_iter` | = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see issue #85684 <https://github.com/rust-lang/rust/issues/85684> warning: 3 warnings emitted </ins>

For generic types, the prelude collision lint can produce suggestions that do not compile: Code: Suggestion from the prelude collision lint: Error after applying the suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
My guess is this should be a simple fix, just copying the code the lint already uses for adding unspecified generics (). Will try implementing a fix soon.
assign
release-assignment
The code related to this lint lives in the . The relevant suggestion is generated here: The "self type" string comes from here: The code for traits is here: This is actually just a touch tricky, because currently we are getting the "self type" just by copying the text the user wrote. Probably the most correct thing for us to do would be to examine the 'self expression' HIR and, if it is a plain path, then to append the and otherwise skip it. Specifically, the other case that I am thinking about is code like this: Currently , meaning that it offers the suggestion "disambiguate the associated function: ".
claim
great! Let us know if you need anything or make progress. This issue is fairly time sensitive.
release-assignment
claim


Question: rustdocflags.arg("-Dwarnings"); } <del> // FIXME(#58633) hide "unused attribute" errors in incremental // builds of the standard library, as the underlying checks are // not yet properly integrated with incremental recompilation. if mode == Mode::Std && compiler.stage == 0 && self.config.incremental { lint_flags.push("-Aunused-attributes"); } </del> // This does not use RUSTFLAGS due to caching issues with Cargo. // Clippy is treated as an "in tree" tool, but shares the same // cache as other "submodule" tools. With these options set in

This error occurred when running . Should I remove these unused attributes?
What's your ? These should only warn, not error.
This is a part of my which is not commented out.
If you run and check again, these warnings should go away. It would be nice if this wasn't necessary, though.
Thank you for your advice! clean and then build completed successfully!
This happens to me every time I try to do an incremental build after making a change. Is there any other way to resolve this than ?
Let's keep this issue open, because we'd rather not have to clean even single time.
I'm running into the same problem with incremental builds, which makes incremental kind of useless...
I think I am also running into this. I'm going to tag this T-compiler to try to increase visibility
I am also running into this
This is super painful, can this gets prioritized, or could we disable incremental builds until its fixed?
FYI, the following command seems like a pretty reliable way to reproduce this problem:
(assigning to self to investigate)
Strange; part of the problem I have had in investigating this is that it seemed like my manual attempts to run the "same" commands that were being issued by bootstrap would all complete successfully. I think part of the issue there is that the mode for is sometimes hiding information about the commands it runs. To get something that actually reproduced the problem, I had to drop into the "more verbose" mode by passing twice to , like so: and an interesting part about that output is that I saw these two lines right next to each other in the output: The first command listed won't reproduce the problem. The second will. (I suspect its because the first is lacking that that is present in the second.)
Also, setting this to may provide an easier workaround for this speciifc bug than a full clean:
(The aforementioned setting was moved into rustbuild in )
I am getting an increasing feeling that we need to document and simplify the bootstrapping process better...
My hope is that once PR gets into the beta-channel, then we should not see this particular problem arise. I would like to know if anyone is seeing other warnings that are not covered by the cases I handled in PR .
This is fixed now, right?
I haven't encountered it since
Same here. Seems to be working. Thanks
closing as fixed.


Question: rustdocflags.arg("-Dwarnings"); } <del> // FIXME(#58633) hide "unused attribute" errors in incremental // builds of the standard library, as the underlying checks are // not yet properly integrated with incremental recompilation. if mode == Mode::Std && compiler.stage == 0 && self.config.incremental { lint_flags.push("-Aunused-attributes"); } </del> // This does not use RUSTFLAGS due to caching issues with Cargo. // Clippy is treated as an "in tree" tool, but shares the same // cache as other "submodule" tools. With these options set in

Fixed on my end as well, thank you all!
Seeing this one here: ie. I attempted some kind of whitelisting just as you did in PR , but I'm thinking it will only work if I attempt recompilation with a rustc that has that whitelisted already?(which would explain why it keeps failing as if whitelisting it had no effect, ok definitely placing garbage instead of the below patch(which should compile fail) does have no effect which says that it doesn't get compiled before the above fail) Either way, I'm not sure where to Whitelist it, since it appears as too: (notice how the filename moved: is now ) Something extra: If I put in (which overrides the stage0 rust / / ) then it compiles ok the first time(as expected) then if I interrupt it and then attempt (re)compile, I get now:
This keeps happening to me with this:
I'm reopening and nominating for compiler team since it seems like it may be worth discussing to see if there's some principled solution for bugs like this. I think we've seen the last 2-3 releases all introduce at least one case of unused attribute errors in libcore/libstd during incremental, which is not great. Maybe there's some way we can stop tracking the rustc-perma-unstable attributes as 'green' in incremental? That may be too big a hammer though (or maybe too small). At least, it seems worth bringing this up at pre-triage.
This keeps happening to me when switching from to . Very annoying to have to . :(
triage: P-high, leaving nominated in hopes of discussion in a near term meeting.
There is a way of dealing with side-effects in the incremental system. We use such a solution for diagnostics. It could probably be expanded to unused-attributes if there is no cleaner approach.
removing nomination label; I'll follow-up with directly on ways to resolve this. (And/or discuss removing lint with )
Should we just demote to warn-only at stage0? It's getting pretty boring to nuke every time I rebase and something has changed in libstd (looks even more frequent nowadays), and I've heard people say they don't set in because of these "unused attribute" errors, which is a shame.


Question: rustdocflags.arg("-Dwarnings"); } <del> // FIXME(#58633) hide "unused attribute" errors in incremental // builds of the standard library, as the underlying checks are // not yet properly integrated with incremental recompilation. if mode == Mode::Std && compiler.stage == 0 && self.config.incremental { lint_flags.push("-Aunused-attributes"); } </del> // This does not use RUSTFLAGS due to caching issues with Cargo. // Clippy is treated as an "in tree" tool, but shares the same // cache as other "submodule" tools. With these options set in

IMO should be the default for dev builds, although there's also the wasteful duplication between build artifacts and incremental dirs (for which I've just opened ).
Opened for the "temporary workaround".
Just FYI, landed, please leave a comment here if you still hit this issue. (it might move from libcore to other crates, not sure)


Question: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::*; #[proc_macro_derive(A, attributes(b))] pub fn foo(_x: TokenStream) -> TokenStream { TokenStream::new() } </ins>

This is the code you are supposed to use according to the lint. It fails to compile, with It compiles fine if you use just one of the two attributes. Swapping attribute order makes it complain about the last non-derive attribute. This seems broken? cc
Confirmed, this behavior is broken. Possibly related to .
As a workaround specific to serde_derive, we allow multiple elements within one attribute.
yeah, that's what I ended up doing
This should be fixed in


Question: #[cfg(any(target_os = "horizon", target_os = "hurd"))] pub fn accessed(&self) -> io::Result<SystemTime> { <del> Ok(SystemTime::from(self.stat.st_atim)) </del> <ins> SystemTime::new(self.stat.st_atim.tv_sec as i64, self.stat.st_atim.tv_nsec as i64) </ins> } #[cfg(any(

Compiling project with causes the following compilation error: See this .
cc target maintainer
I guess has the same issue? This got broken by ("unix time module now return result") which dropped I guess the way forward is to make use instead. I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?
Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.
Sure, I'm not saying to block PRs, but I'm wondering about somehow getting notified quickly enough to be able to react before a rustc release.
(as in: getting the break notice from a getrandom CI build a dozen days after the merge does not look that robust)
Hm. Does the Rust compiler for hurd get built from a stable or beta branch of rustc? My understanding was that tier 3 targets generally used the nightly compiler in any case.
In Debian we will use the stable releases to compile all rust-needing Debian packages, as the Debian policy requires.
The breaking commit is not in the current 1.77 release but is in the 1.78 beta. It will not be in a stable release for another 5 weeks-ish. Would you like your PR that fixes it to be beta-nominated, so that it gets backported and is in the stable release of 1.78?
Yes, please.
I recommend you set up a daily/weekly job on your side building master to check for regressions. ( may fix this)


Question: use DefModifiers; use Module; <ins> use ModuleKind; </ins> use Namespace::{self, TypeNS, ValueNS}; use NameBindings; use NamespaceResult::{BoundResult, UnboundResult, UnknownResult};

I found an error message that seems a bit off to me. The code: Clearly it should fail to compile, and it does. But the error message is: I would expect something like "a module name has already been imported", instead. Is it accurate to call it a type?


Question: <ins> error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL | fn wat<T>(t: &T) -> T { |        -            - expected `T` because of return type |        | |        this type parameter LL |     t.clone() |     ^^^^^^^^^ expected type parameter `T`, found `&T` | = note: expected type parameter `T` found reference `&T` note: `T` does not implement `Clone`, so `&T` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL |     t.clone() |     ^ help: consider restricting type parameter `T` | LL | fn wat<T: Clone>(t: &T) -> T { |         +++++++ error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL | fn wut(t: &Foo) -> Foo { |                    --- expected `Foo` because of return type LL |     t.clone() |     ^^^^^^^^^ expected struct `Foo`, found `&Foo` | note: `Foo` does not implement `Clone`, so `&Foo` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL |     t.clone() |     ^ help: consider annotating `Foo` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"


Question: <ins> // Regression test for #72051, hang when resolving regions. // check-pass // edition:2018 pub async fn query<'a>(_: &(), _: &(), _: (&(dyn std::any::Any + 'a),) ) {} fn main() {} </ins>

() Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .


Question: ``` ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType` ``` <ins> Note that this does not move `v` (unlike `transmute`), and may need a call to `mem::forget(v)` in case you want to avoid destructors being called. </ins> "##, E0152: r##"

The message for E0139 suggests replacing with . Actually performing such a replacement will result in double drops, since the version consumes but the version does not. (It presumably needs a or something.)


Question: ``` ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType` ``` <ins> Note that this does not move `v` (unlike `transmute`), and may need a call to `mem::forget(v)` in case you want to avoid destructors being called. </ins> "##, E0152: r##"

On currently nightly, I get: () Yet the description for this error was merged weeks ago:
cc , in the future when adding new diagnostics mods be sure to add a call


Question: } } <del> fn type_bound( &self, ty: Ty<'tcx>, visited: &mut SsoHashSet<GenericArg<'tcx>>, ) -> VerifyBound<'tcx> { match *ty.kind() { ty::Param(p) => self.param_bound(p), ty::Projection(data) => self.projection_bound(data, visited), ty::FnDef(_, substs) => { // HACK(eddyb) ignore lifetimes found shallowly in `substs`. // This is inconsistent with `ty::Adt` (including all substs), // but consistent with previous (accidental) behavior. // See https://github.com/rust-lang/rust/issues/70917 // for further background and discussion. let mut bounds = substs .iter() .filter_map(|child| match child.unpack() { GenericArgKind::Type(ty) => Some(self.type_bound(ty, visited)), GenericArgKind::Lifetime(_) => None, GenericArgKind::Const(_) => Some(self.recursive_bound(child, visited)), }) .filter(|bound| { // Remove bounds that must hold, since they are not interesting. !bound.must_hold() }); match (bounds.next(), bounds.next()) { (Some(first), None) => first, (first, second) => VerifyBound::AllBounds( first.into_iter().chain(second).chain(bounds).collect(), ), } } _ => self.recursive_bound(ty.into(), visited), } } </del> fn param_bound(&self, param_ty: ty::ParamTy) -> VerifyBound<'tcx> { debug!("param_bound(param_ty={:?})", param_ty);

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.