Question: #![allow(unused_macros)] <ins> // Tests that repetition matchers cannot match the empty token tree (since that would be // ambiguous). // edition:2018 </ins> macro_rules! foo { ( $()* ) => {}; //~^ ERROR repetition matches empty token tree ( $()+ ) => {}; //~^ ERROR repetition matches empty token tree <ins> ( $()? ) => {}; //~^ ERROR repetition matches empty token tree </ins> ( $(),* ) => {}; // PASS ( $(),+ ) => {}; // PASS <ins> // `?` cannot have a separator... </ins> ( [$()*] ) => {}; //~^ ERROR repetition matches empty token tree ( [$()+] ) => {}; //~^ ERROR repetition matches empty token tree <ins> ( [$()?] ) => {}; //~^ ERROR repetition matches empty token tree </ins> ( [$(),*] ) => {}; // PASS ( [$(),+] ) => {}; // PASS <ins> // `?` cannot have a separator... </ins> ( $($()* $(),* $(a)* $(a),* )* ) => {}; //~^ ERROR repetition matches empty token tree ( $($()* $(),* $(a)* $(a),* )+ ) => {}; //~^ ERROR repetition matches empty token tree <ins> ( $($()* $(),* $(a)* $(a),* )? ) => {}; //~^ ERROR repetition matches empty token tree ( $($()? $(),* $(a)? $(a),* )* ) => {}; //~^ ERROR repetition matches empty token tree ( $($()? $(),* $(a)? $(a),* )+ ) => {}; //~^ ERROR repetition matches empty token tree ( $($()? $(),* $(a)? $(a),* )? ) => {}; //~^ ERROR repetition matches empty token tree </ins> ( $(a     $(),* $(a)* $(a),* )* ) => {}; // PASS ( $($(a)+ $(),* $(a)* $(a),* )+ ) => {}; // PASS <ins> ( $($(a)+ $(),* $(a)* $(a),* )? ) => {}; // PASS ( $(a     $(),* $(a)? $(a),* )* ) => {}; // PASS ( $($(a)+ $(),* $(a)? $(a),* )+ ) => {}; // PASS ( $($(a)+ $(),* $(a)? $(a),* )? ) => {}; // PASS </ins> ( $(a $()+)* ) => {}; //~^ ERROR repetition matches empty token tree ( $(a $()*)+ ) => {}; //~^ ERROR repetition matches empty token tree <ins> ( $(a $()+)? ) => {}; //~^ ERROR repetition matches empty token tree ( $(a $()?)+ ) => {}; //~^ ERROR repetition matches empty token tree </ins> } // --- Original Issue --- // macro_rules! make_vec {

The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened


Question: [95818]: https://github.com/rust-lang/rust/pull/95818/ [95897]: https://github.com/rust-lang/rust/pull/95897/ [95953]: https://github.com/rust-lang/rust/pull/95953/ <ins> [96051]: https://github.com/rust-lang/rust/pull/96051/ </ins> [96296]: https://github.com/rust-lang/rust/pull/96296/ [96455]: https://github.com/rust-lang/rust/pull/96455/ [96737]: https://github.com/rust-lang/rust/pull/96737/

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?


Question: config.download_beta_toolchain(); config.out.join(config.build.triple).join("stage0/bin/rustc") }); config.initial_cargo = build .cargo .map(|cargo| {

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


Question: config.download_beta_toolchain(); config.out.join(config.build.triple).join("stage0/bin/rustc") }); config.initial_cargo = build .cargo .map(|cargo| {

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


Question: #[rustc_doc_primitive = "f32"] #[doc(alias = "single")] <del> /// A 32-bit floating point type (specifically, the "binary32" type defined in IEEE 754-2008). </del> <ins> /// A 32-bit floating-point type (specifically, the "binary32" type defined in IEEE 754-2008). </ins> /// /// This type can represent a wide range of decimal numbers, like `3.5`, `27`, /// `-113.75`, `0.0078125`, `34359738368`, `0`, `-1`. So unlike integer types <del> /// (such as `i32`), floating point types can represent non-integer numbers, </del> <ins> /// (such as `i32`), floating-point types can represent non-integer numbers, </ins> /// too. /// /// However, being able to represent this wide range of numbers comes at the

Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .


Question: if i != 0 || j != lines.len() { Some((i, j)) } else { None } } <del> fn get_horizontal_trim(lines: &[&str], kind: CommentKind) -> Option<usize> { </del> <ins> fn get_horizontal_trim<'a>(lines: &'a [&str], kind: CommentKind) -> Option<String> { </ins> let mut i = usize::MAX; let mut first = true;

Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.


Question: return ret; } <ins> fn verify_rustc_version(&self, name: &str, span: Span, metadata: &MetadataBlob) { let crate_rustc_version = decoder::crate_rustc_version(metadata.as_slice()); if crate_rustc_version != Some(rustc_version()) { span_err!(self.sess, span, E0514, "the crate `{}` has been compiled with {}, which is  incompatible with this version of rustc", name, crate_rustc_version .as_ref().map(|s|&**s) .unwrap_or("an old version of rustc") ); self.sess.abort_if_errors(); } } </ins> fn register_crate(&mut self, root: &Option<CratePaths>, ident: &str,

When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata


Question: <ins> error[E0404]: expected trait, found type alias `Strings` --> $DIR/suggest-trait-alias-instead-of-type.rs:10:18 | LL | struct Struct<S: Strings>(S); |                  ^^^^^^^ type aliases cannot be used as traits | help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias | LL | trait Strings = Iterator<Item=String>; | error: aborting due to previous error For more information about this error, try `rustc --explain E0404`. </ins>

I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).


Question: extra_args.push("--disable-minification"); } <del> doc_std(builder, self.format, stage, target, &out, &extra_args, &self.crates); </del> <ins> doc_std(builder, self.format, stage, target, &out, &extra_args, &crates); </ins> // Don't open if the format is json if let DocumentationFormat::Json = self.format {

I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.


Question: <ins> trait T { type A: S<C<i32 = u32> = ()>; //~^ ERROR associated type bindings are not allowed here } trait Q {} trait S { type C: Q; } fn main() {} </ins>

I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


Question: // present. However, we first need to strip the empty lines so they don't get in the middle // when we try to compute the "horizontal trim". let lines = if kind == CommentKind::Block { <del> let mut i = 0; </del> <ins> // Whatever happens, we skip the first line. let mut i = if lines[0].trim_start().starts_with('*') { 0 } else { 1 }; </ins> let mut j = lines.len(); while i < j && lines[i].trim().is_empty() {


Question: /// [`NotConnected`]: ../../std/io/enum.ErrorKind.html#variant.NotConnected /// /// ```no_run <del> /// #![feature(udp_peer_addr)] </del> /// use std::net::UdpSocket; /// /// let socket = UdpSocket::bind("127.0.0.1:34254").expect("couldn't bind to address"); /// assert_eq!(socket.peer_addr().unwrap_err().kind(), ///            ::std::io::ErrorKind::NotConnected); /// ``` <del> #[unstable(feature = "udp_peer_addr", issue = "59127")] </del> <ins> #[stable(feature = "udp_peer_addr", since = "1.40.0")] </ins> pub fn peer_addr(&self) -> io::Result<SocketAddr> { self.0.peer_addr() }

Tracking issue for making on stable: ,
FYI, in Rust issue tracker, "tracking issue" is a jargon for stabilizing features already in nightly. As I understand, is not yet in nightly?
A tracking issue has to be opened before a feature can land in nightly, because the attribute needs an issue number to refer to. has also been approved already, so it'll land in one of the next nightlies.
How about moving this to stable?
What's left to do to stabilize this feature? Any ETA?
Can this be stablised for 1.37?
Another reminder -- can we kick off FCP for stabilization?
any updates?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.


Question: // This is something like impl Trait1 for Trait2. Illegal // if Trait1 is a supertrait of Trait2 or Trait2 is not object safe. <del> if let Some(principal_def_id) = data.principal_def_id() { if !tcx.is_object_safe(principal_def_id) { </del> <ins> let component_def_ids = data.iter().flat_map(|predicate| { match predicate.skip_binder() { ty::ExistentialPredicate::Trait(tr) => Some(tr.def_id), ty::ExistentialPredicate::AutoTrait(def_id) => Some(*def_id), // An associated type projection necessarily comes with // an additional `Trait` requirement. ty::ExistentialPredicate::Projection(..) => None, } }); for component_def_id in component_def_ids { if !tcx.is_object_safe(component_def_id) { </ins> // This is an error, but it will be reported by wfcheck.  Ignore it here. // This is tested by `coherence-impl-trait-for-trait-object-safe.rs`. } else { let mut supertrait_def_ids = <del> traits::supertrait_def_ids(tcx, principal_def_id); </del> <ins> traits::supertrait_def_ids(tcx, component_def_id); </ins> if supertrait_def_ids.any(|d| d == trait_def_id) { let sp = tcx.sess.source_map().def_span(tcx.span_of_impl(impl_def_id).unwrap()); struct_span_err!(tcx.sess,

Code gives the same error as , giving (dyn Xyz + Abc + 'static)XyzCode passes coherence, but wfcheck fails because of the confusion:


Question: #[stable(feature = "ip_u32", since = "1.1.0")] impl From<u32> for Ipv4Addr { <ins> /// It performs the conversion in network order (big-endian). </ins> fn from(ip: u32) -> Ipv4Addr { Ipv4Addr::new((ip >> 24) as u8, (ip >> 16) as u8, (ip >> 8) as u8, ip as u8) }

The conversion traits are implemented for conversion between and , but it is not clear what byte order is used.
It is network order, but that should be documented on the impl.
doc team triage: this would make a great first PR. I am happy to mentor anyone who wants to tackle this issue.
I'd like to, is someone else working on this?
nope, please do! Ping me if you need any help


Question: #![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)


Question: #![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.


Question: #![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.


Question: #![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!


Question: StyledBuffer { text: vec![], styles: vec![] } } <del> fn replace_tabs(&mut self) { for (line_pos, line) in self.text.iter_mut().enumerate() { let mut tab_pos = vec![]; for (pos, c) in line.iter().enumerate() { if *c == 't' { tab_pos.push(pos); } } // start with the tabs at the end of the line to replace them with 4 space chars for pos in tab_pos.iter().rev() { assert_eq!(line.remove(*pos), 't'); // fix the position of the style to match up after replacing the tabs let s = self.styles[line_pos].remove(*pos); for _ in 0..4 { line.insert(*pos, ' '); self.styles[line_pos].insert(*pos, s); } } } } </del> <ins> pub fn render(&self) -> Vec<Vec<StyledString>> { // Tabs are assumed to have been replaced by spaces in calling code. assert!(self.text.iter().all(|r| !r.contains(&'t'))); </ins> <del> pub fn render(&mut self) -> Vec<Vec<StyledString>> { </del> let mut output: Vec<Vec<StyledString>> = vec![]; let mut styled_vec: Vec<StyledString> = vec![]; <del> // before we render, replace tabs with spaces self.replace_tabs(); </del> for (row, row_style) in self.text.iter().zip(&self.styles) { let mut current_style = Style::NoStyle; let mut current_text = String::new();

The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim


Question: <ins> // check-pass fn main() { println!("{:?}", { type T = (); pub fn cloneit(it: &'_ mut T) -> (&'_ mut T, &'_ mut T) where for<'any> &'any mut T: Clone, { (it.clone(), it) } }); } </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. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- 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</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?


Question: <ins> // check-pass fn main() { println!("{:?}", { type T = (); pub fn cloneit(it: &'_ mut T) -> (&'_ mut T, &'_ mut T) where for<'any> &'any mut T: Clone, { (it.clone(), it) } }); } </ins>

Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- 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. --: Reproducible on beta and nightly <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim


Question: ("stable", Whitelisted, template!(List: r#"feature = "name", since = "version""#), Ungated), ("unstable", Whitelisted, template!(List: r#"feature = "name", reason = "...", issue = "N""#), Ungated), <del> ("deprecated", Normal, template!(Word, List: r#"/*opt*/ since = "version", /*opt*/ note = "reason"#, NameValueStr: "reason"), Ungated), </del> <ins> ("deprecated", Normal, template!( Word, List: r#"/*opt*/ since = "version", /*opt*/ note = "reason"#, NameValueStr: "reason" ), Ungated ), </ins> ("rustc_paren_sugar", Normal, template!(Word), Gated(Stability::Unstable, "unboxed_closures",

Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .


Question: // We don't emit documentation for default items if they appear in the // Implementations on Foreign Types or Implementors sections. if rendering_params.show_default_items { <del> if let Some(t) = trait_ { </del> <ins> if let Some(t) = trait_ && !impl_.is_negative_trait_impl() { </ins> render_default_items( &mut default_impl_items, &mut impl_items, cx, t, <del> i.inner_impl(), </del> <ins> impl_, </ins> &i.impl_item, render_mode, rendering_params,

<p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.


Question: param_mode: ParamMode, itctx: ImplTraitContext, ) -> hir::Ty<'hir> { <ins> // Check whether we should interpret this as a bare trait object. // This check mirrors the one in late resolution.  We only introduce this special case in // the rare occurence we need to lower `Fresh` anonymous lifetimes. // The other cases when a qpath should be opportunistically made a trait object are handled // by `ty_path`. if qself.is_none() && let Some(partial_res) = self.resolver.get_partial_res(t.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { let (bounds, lifetime_bound) = self.with_dyn_type_scope(true, |this| { let bound = this.lower_poly_trait_ref( &PolyTraitRef { bound_generic_params: vec![], trait_ref: TraitRef { path: path.clone(), ref_id: t.id }, span: t.span }, itctx, ); let bounds = this.arena.alloc_from_iter([bound]); let lifetime_bound = this.elided_dyn_bound(t.span); (bounds, lifetime_bound) }); let kind = hir::TyKind::TraitObject(bounds, lifetime_bound, TraitObjectSyntax::None); return hir::Ty { kind, span: self.lower_span(t.span), hir_id: self.next_id() }; } </ins> let id = self.lower_node_id(t.id); let qpath = self.lower_qpath(t.id, qself, path, param_mode, itctx); self.ty_path(id, t.span, qpath)

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code with : I expected to see only warning without error, like this: Instead, this happened (extra error E0521 emitted, which is incorrect): If I add in line 3, it compiles without any error or warning: So the E0521 error emitted by the compiler is incorrect. The test code using should only produce warnings without an error. It most recently worked on: 1.63.0-nightly ( 2022-05-18) </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
labels:+T-compiler
label A-diagnostics
labels: +regression-from-stable-to-nightly
label -regression-untriaged Bisection: regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: that’s , cc
Seems like, possibly, the code without the explicit (incorrectly) desugars to rather than Edit: Or perhaps it incorrectly desugars to
Here’s another kind of code example that reproduces the issue Which does confirm the idea that this appears to be interpreted like , rather than which would be correct.
WG-prioritization assigning priority (). label -I-prioritize +P-critical


Question: param_mode: ParamMode, itctx: ImplTraitContext, ) -> hir::Ty<'hir> { <ins> // Check whether we should interpret this as a bare trait object. // This check mirrors the one in late resolution.  We only introduce this special case in // the rare occurence we need to lower `Fresh` anonymous lifetimes. // The other cases when a qpath should be opportunistically made a trait object are handled // by `ty_path`. if qself.is_none() && let Some(partial_res) = self.resolver.get_partial_res(t.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { let (bounds, lifetime_bound) = self.with_dyn_type_scope(true, |this| { let bound = this.lower_poly_trait_ref( &PolyTraitRef { bound_generic_params: vec![], trait_ref: TraitRef { path: path.clone(), ref_id: t.id }, span: t.span }, itctx, ); let bounds = this.arena.alloc_from_iter([bound]); let lifetime_bound = this.elided_dyn_bound(t.span); (bounds, lifetime_bound) }); let kind = hir::TyKind::TraitObject(bounds, lifetime_bound, TraitObjectSyntax::None); return hir::Ty { kind, span: self.lower_span(t.span), hir_id: self.next_id() }; } </ins> let id = self.lower_node_id(t.id); let qpath = self.lower_qpath(t.id, qself, path, param_mode, itctx); self.ty_path(id, t.span, qpath)

ndarray 0.9.1 compiles with rustc 1.61.0 but not with rustc 1.64.0-nightly ( 2022-06-27). Put this into a of a new project: rustc stable <= 1.61.0 compiles the crate fine, rustc nightly gives the following error: modify labels: +regression-from-stable-to-nightly -regression-untriaged
Just adding a note. The issue seems to be an old version of that used to use back in v0.9.1 <details</detailsThe crate from v0.13.0 (released in sept. 2019) compiles fine also on latest Rust nightly
bisection seems to point to commit cc searched nightlies: from nightly-2022-04-01 to nightly-2022-06-28 regressed nightly: nightly-2022-06-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details(unsure if this regression may hit other more recent crates)
I've been suspecting this bug for a few days, but unable to reproduce it. I think I have a patch, will confirm once I manage to MCVE.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: match MyOption::MySome(42) { MyOption::MySome { x: 42 } => (), //~^ ERROR variant `MyOption::MySome` does not have a field named `x` <del> //~| ERROR pattern does not mention field `0` </del> _ => (), } }

With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .


Question: /// /// Run a future to completion on the current thread. /// fn block_on<T>(fut: impl Future<Output = T>) -> T { ///     // Pin the future so it can be polled. <del> ///     let mut fut = Box::pin(fut); </del> <ins> ///     let mut fut = pin!(fut); </ins> /// ///     // Create a new context to be passed to the future. ///     let t = thread::current();

The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks


Question: // since we may be in the process of computing this MIR in the // first place. let layout = if def_id == self.caller_body.source.def_id() { <del> // FIXME: This is not right for async closures. </del> <ins> self.caller_body.coroutine_layout_raw() } else if let Some(hir::CoroutineKind::Desugared( _, hir::CoroutineSource::Closure, )) = self.tcx.coroutine_kind(def_id) && let ty::ClosureKind::FnOnce = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap() && self.caller_body.source.def_id() == self.tcx.coroutine_by_move_body_def_id(def_id) { // Same if this is the by-move body of a coroutine-closure. </ins> self.caller_body.coroutine_layout_raw() } else { self.tcx.coroutine_layout(def_id, args.as_coroutine().kind_ty())

Originally posted at and filing this upon request from . We're using nightly rust and as of nightly-2024-08-29 (prior to this it compiled fine) we see the following error: Function being flagged can be viewed at . We're having a bit of a hard time debugging this issue, it's not very clear what this actually means. I've tried looking at the HIR output but it didn't really help and I'm a bit lost on this one as I'm not familiar with MIR. I expected to see this happen: Compilation succeed. Instead, this happened: Compilation failed due to MIR cycle. : Backtrace contained no extra information.
this kind of looks like it should be an ICE instead? :thinking:
I'll try to put up a fix. It's due to (not that you need to understand what that PR does), not your fault.
For now, though, you'll need to either stop using closures (since you've got an bound, not ; why are you using closures over just , since those don't really buy you anything in this case?) or pin your nightly compiler version until I can minimize this and fix it.
Minimized: To reproduce: (Odd that the "optimization" also happens in debug builds.) Of note: During the minimization process, rust-analyzer froze multiple times. And a few times, also froze.
you're awesome! thanks for the minimization.
Thanks for confirming. We were having a lot of issues with lifetimes when using the async blocks which lead to us using async closures instead. Possibly we should just revisit that...
You might be interested in these two links for an explanation on how exactly async closures differ from a closure that returns an async block: https://rust-
Thanks I'll take a look at those.


Question: "bad output4: {}", s); } <del> #[cfg(not(all(windows, target_arch = "x86")))] </del> fn main() { <ins> if cfg!(windows) && cfg!(target_arch = "x86") && cfg!(target_env = "gnu") { return } </ins> let args: Vec<String> = env::args().collect(); if args.len() >= 2 && args[1] == "fail" { foo();

Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.


Question: } let definition_ty = instantiated_ty <del> .remap_generic_params_to_declaration_params(opaque_type_key, self.tcx, false, origin) </del> <ins> .remap_generic_params_to_declaration_params(opaque_type_key, self.tcx, false) </ins> .ty; if !check_opaque_type_parameter_valid(

Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that


Question: | ----- in this macro invocation error: expected identifier, found reserved identifier `$crate` <del> --> $DIR/dollar-crate-is-keyword.rs:11:23 </del> <ins> --> $DIR/dollar-crate-is-keyword.rs:10:23 </ins> | LL |         use $crate as $crate; |                       ^^^^^^ expected identifier, found reserved identifier

The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.


Question: = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <del> error: aborting due to 5 previous errors </del> <ins> error[E0658]: the `!` type is experimental --> $DIR/feature-gate-never_type.rs:16:43 | LL | fn look_ma_no_feature_gate<F: FnOnce() -> !>() {} |                                           ^ | = note: see issue #35121 <https://github.com/rust-lang/rust/issues/35121> for more information = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0658]: the `!` type is experimental --> $DIR/feature-gate-never_type.rs:17:26 | LL | fn tadam(f: &dyn Fn() -> !) {} |                          ^ | = note: see issue #35121 <https://github.com/rust-lang/rust/issues/35121> for more information = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0658]: the `!` type is experimental --> $DIR/feature-gate-never_type.rs:21:30 | LL | fn toudoum() -> impl Fn() -> ! { |                              ^ | = note: see issue #35121 <https://github.com/rust-lang/rust/issues/35121> for more information = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error: aborting due to 8 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet for ). <!-- 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. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.


Question: // The correct solution would be to add symbolic computations to miri, // so we wouldn't have to compute and store the actual value <del> let hir::ExprKind::Path(ref qpath) = source.kind else { return ExprKind::Cast { source: self.mirror_expr(source) }; }; let res = self.typeck_results().qpath_res(qpath, source.hir_id); let ty = self.typeck_results().node_type(source.hir_id); let ty::Adt(adt_def, args) = ty.kind() else { return ExprKind::Cast { source: self.mirror_expr(source) }; }; let Res::Def(DefKind::Ctor(CtorOf::Variant, CtorKind::Const), variant_ctor_id) = res else { return ExprKind::Cast { source: self.mirror_expr(source) }; }; </del> let idx = adt_def.variant_index_with_ctor_id(variant_ctor_id); let (discr_did, discr_offset) = adt_def.discriminant_def_for_variant(idx);

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: . I expected to see this happen: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.


Question: adt_def, variant_index: adt_def.variant_index_with_ctor_id(def_id), substs, <del> user_ty: user_provided_type, </del> <ins> user_ty, </ins> fields: vec![], base: None, }, <ins> _ if ty.references_error() => { // Handle degenerate input without ICE (#67377). ExprKind::Literal { literal: ty::Const::zero_sized(cx.tcx, cx.tcx.types.err), user_ty: None, } } </ins> _ => bug!("unexpected ty: {:?}", ty), } }

The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc


Question: .map(|lazy| lazy.decode((cdata, tcx))) .process_decoded(tcx, || panic!("{def_id:?} does not have trait_impl_trait_tys"))) } <del> implied_predicates_of => { cdata .root .tables .implied_predicates_of .get(cdata, def_id.index) .map(|lazy| lazy.decode((cdata, tcx))) .unwrap_or_else(|| { debug_assert_eq!(tcx.def_kind(def_id), DefKind::Trait); tcx.super_predicates_of(def_id) }) } </del> associated_types_for_impl_traits_in_associated_fn => { table_defaulted_array }

<!-- 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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry


Question: panic::panic_any(InjectedFailure) ); }); <del> assert_eq!(get(), vec![14, 19, 20, 17, 15, 11, 18, 16, 12, 13]); </del> <ins> assert_eq!(get(), vec![20, 17, 15, 11, 19, 18, 16, 12, 14, 13]); </ins> }

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


Question: panic::panic_any(InjectedFailure) ); }); <del> assert_eq!(get(), vec![14, 19, 20, 17, 15, 11, 18, 16, 12, 13]); </del> <ins> assert_eq!(get(), vec![20, 17, 15, 11, 19, 18, 16, 12, 14, 13]); </ins> }

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


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505.rs:14:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:19:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:24:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505.rs:29:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:34:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:39:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

is an incorrect suggestion because has higher precedence than . It should suggest .
If someone wants to tackle this issue, it should be straightforward to fix. In: there should be another branch for , where the path of the call is . This code is a good reference: This issue affects the other range syntaxes too, so those should also be fixed (although these are not — look at for clues).
Hi I'd like to tackle this and take the plunge into the Rust compiler code :)
great! Let me know if you hit any snags or need any more tips. You'll want to add tests for these (in ). The is a good place for general information about the compiler. When you're done, include in the pull request and I'll review it!
you've anticipated most of my newbie questions already :) Thanks for that info, very useful! I'm now in the process of stressing my PC with lots of compiling to actually get started. Skimming the test code I'm really impressed by how easy it is to add "UI" tests for these sorts of things (compile this, expect this error on this line). Snazzy! That's all great, but do you anticipate I should also add "deeper" tests? I guess I'm trying to understand if the scope of this is just pure UI or do I need to touch some syntax parsing/immediate representations, since you mentioned code in . Because the compiler is emitting a syntax suggestion, we might want to assert that the suggestion is correct syntax in the first place. I don't know if that's how deep the rabbit hole goes and if there's a facility to help out, but my hunch is that since we have all of the compiler at hand, why not use it to validate the suggestion syntax? EDIT: OK, reading up on adding new tests to the compiler I encountered mention of , and it seems to be sort-of what I was after.
The issue here is just a diagnostic issue, so checking that we're getting the updated hint is enough. The code in is just helpful to see what ranges like and are desugared into, so you can catch them in — you shouldn't need to modify anything (apart from the test) outside of . It would technically be possible to do something like this, but it would probably be more trouble than it's worth.


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505.rs:14:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:19:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:24:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505.rs:29:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:34:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:39:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

(I'm not aware of a facility to do this easily already.) I think manually going through the possible s and checking that the parenthesisation behaviour is correct in each case would be a lot simpler: if we handle the different s in an exhaustive now (it's likely that if the ranges were handled incorrectly, there could be some others that are also missed at the moment), then this should be a one-time fix and the tests should prevent it regressing. A simple UI test should be sufficient here: will generate the output files, which will include all the relevant notes.
There was a similar problem with the suggestions, and it was fixed in . Further use of the operator precedence list can be seen in (which introduced the error fixed in the other PR).
Thanks for your guidance and much appreciated. I have dug into HIR and built-in ranges a bit more. Decided to check all the built-in range types and concluded they are all indeed affected by this problem. The following test I came up with demonstrates my intended fix (fails with nightly as well as stage 1 compiled from master): None of the fix suggestions, when applied, constitute valid syntax. My test checks for syntax I believe should be suggested by the compiler. I'm keen to tackle all of the range types at once in the scope of this issue. The problem I see though is just how wildly different each of the range types is represented in HIR. Adding a call just above this line: Revealed the following: for isfor isfor isfor isfor isfor is I'm quite bewildered by this non-uniformity and I guess I need some help unifying all of these into a elegant condition to tell "is this a built-in range?". I could probably brute-force it in a with explicit checks for , but maybe we can do better. Thanks in advance! EDIT realized that this non-uniformity was actually mentioned in the second comment from , but my plea still stands. Thanks for your patience.
I think you can match on all of these with something along the lines of (pseudocode):
Right, that's what I had in mind, but was also wondering if something like a check for  trait would work better. I guess we want to match against built-in range literals though, and explicitly.


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505.rs:14:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:19:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:24:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505.rs:29:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:34:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:39:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Here's how I rationalize it: because they are parsed and desugared by the compiler, the check needs to be explicit and hardcode all paths to builtin ranges. Handle a special case with a special case.
Yes, this is where the lowering code comes in handy, because you can see exactly how the different syntax is desugared differently, to make sure you really are catching all the cases. Yes, I agree. It'd be nice if there was a more uniform way to handle them, but it's not convenient at the moment. You could include a reference back to in a comment to where the desugaring takes place, which will provide some motivation for matching in .
All clear now, thanks. I have succeeded in matching all range types and getting the test to pass. Needs some cleanups, but hopefully should be ready for PR soon. I have a few more questions before that though :smile: I have noticed that most of my code would actually be irrelevant if I re-used functions and constants defined in , e.g.: Can't deny that I have used these as inspiration / guideline (albeit I did not do a stupid copy-paste). What's the policy on using clippy code (clippy is a submodule of main repo)? This is purely in the interest of pursuing . The diff is not that big (52 new lines to , fairly specific to matching paths) -- but still, my clean code sense tingles because of possible DRY violation. Another conundrum I have is whether we should address and paths (and if so, how to work out we're not using at compile time)?
Unfortunately, there's not much sharing from clippy to rustc. I wouldn't worry about it. If you can encapsulate it easily, it's possible that clippy could make use of the code in rustc instead. The function in picks the correct path for / — you should be able to use that.
Thanks for the suggestion for , unfortunately I can't really make the association of and . It seems to me they are disjoint -- in : lowering happens in , whereas typechecking happens in . in takes : The it uses needs an awful lot of things to be instantiated. Not sure if I can get the hold of it all in .


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505.rs:14:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:19:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:24:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505.rs:29:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:34:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:39:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.


Question: pub type ExternType; } <ins> pub trait T { fn test(&self) {} } pub trait G<N> { fn g(&self, n: N) {} } </ins> impl ExternType { <del> pub fn f(&self) { </del> <ins> pub fn f(&self) {} } </ins> <del> } </del> <ins> impl T for ExternType { fn test(&self) {} } impl G<usize> for ExternType { fn g(&self, n: usize) {} </ins> } // @has 'extern_type/foreigntype.ExternType.html' // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.f"' <ins> // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.test"' // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.g"' </ins> /// See also [ExternType::f] <ins> /// See also [ExternType::test] /// See also [ExternType::g] </ins> pub fn links_to_extern_type() {}

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Example code: docs build successfully on 1.57.0: docs fail to build on 1.59.0-nightly ( 2022-01-04): </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --The generics appear necessary for the bug. Removing them from either the type or the trait resolves the failure. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably . searched nightlies: from nightly-2022-01-06 to nightly-2022-01-07 regressed nightly: nightly-2022-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
just saw this, I think might be caused by this change: I'm looking into it
claim


Question: } #[test] <ins> fn test_str_from_utf8_lossy() { let xs = bytes!("hello"); assert_eq!(from_utf8_lossy(xs), ~"hello"); let xs = bytes!("ศไทย中华Việt Nam"); assert_eq!(from_utf8_lossy(xs), ~"ศไทย中华Việt Nam"); let xs = bytes!("Hello", 0xC2, " There", 0xFF, " Goodbye"); assert_eq!(from_utf8_lossy(xs), ~"HellouFFFD ThereuFFFD Goodbye"); let xs = bytes!("Hello", 0xC0, 0x80, " There", 0xE6, 0x83, " Goodbye"); assert_eq!(from_utf8_lossy(xs), ~"HellouFFFDuFFFD ThereuFFFD Goodbye"); let xs = bytes!(0xF5, "foo", 0xF5, 0x80, "bar"); assert_eq!(from_utf8_lossy(xs), ~"uFFFDfoouFFFDuFFFDbar"); let xs = bytes!(0xF1, "foo", 0xF1, 0x80, "bar", 0xF1, 0x80, 0x80, "baz"); assert_eq!(from_utf8_lossy(xs), ~"uFFFDfoouFFFDbaruFFFDbaz"); let xs = bytes!(0xF4, "foo", 0xF4, 0x80, "bar", 0xF4, 0xBF, "baz"); assert_eq!(from_utf8_lossy(xs), ~"uFFFDfoouFFFDbaruFFFDuFFFDbaz"); let xs = bytes!(0xF0, 0x80, 0x80, 0x80, "foo", 0xF0, 0x90, 0x80, 0x80, "bar"); assert_eq!(from_utf8_lossy(xs), ~"uFFFDuFFFDuFFFDuFFFDfooU00010000bar"); // surrogates let xs = bytes!(0xED, 0xA0, 0x80, "foo", 0xED, 0xBF, 0xBF, "bar"); assert_eq!(from_utf8_lossy(xs), ~"uFFFDuFFFDuFFFDfoouFFFDuFFFDuFFFDbar"); } #[test] </ins> fn test_to_send_str() { assert_eq!("abcde".to_send_str(), SendStrStatic("abcde")); assert_eq!("abcde".to_send_str(), SendStrOwned(~"abcde"));

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


Question: <ins> error[E0507]: cannot move out of `var`, a captured variable in an `FnMut` closure --> $DIR/option-content-move2.rs:9:9 | LL |     let mut var = None; |         ------- captured outer variable ... LL |         move || { |         ^^^^^^^ move out of `var` occurs here LL | LL |             var = Some(NotCopyable); |             --- |             | |             move occurs because `var` has type `std::option::Option<NotCopyable>`, which does not implement the `Copy` trait |             move occurs due to use in closure error: aborting due to previous error For more information about this error, try `rustc --explain E0507`. </ins>

gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler


Question: <del> Subproject commit 130721d6f4e6cba3b910ccdf5e0aa62b9dffc95f </del> <ins> Subproject commit 027e428197f3702599cfbb632883768175f49173 </ins>

The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.


Question: <ins> error: unknown start of token: u{2a75} --> $DIR/unicode-double-equals-recovery.rs:1:16 | LL | const A: usize ⩵ 2; |                ^ | help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not | LL | const A: usize == 2; |                ~~ error: unexpected `==` --> $DIR/unicode-double-equals-recovery.rs:1:16 | LL | const A: usize ⩵ 2; |                ^ | help: try using `=` instead | LL | const A: usize = 2; |                ~ error: aborting due to 2 previous errors </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: <ins> // check-pass // compile-flags:--test // This test ensures that no code block is detected in the doc comments. pub mod Wormhole { /** # Returns * */ pub fn foofoo() {} /** * # Returns * */ pub fn barbar() {} } </ins>

Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.


Question: <ins> // Copyright 2017 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() { for i 0..2 { } } </ins>

Hello, with rustc 1.17.0-nightly ( 2017-03-22), the following code gives this error message: An improved error message could add a hint :
Current output: 1) How would you want to improve upon this? Adding a suggestion? 2) To do so, we could use the same strategy as in : in , try to continue building the expression as if the keyword had been found. If we find further errors, we revert the state of the compiler to right after trying to continue and return the error from . Otherwise we cancel that one and create a new custom diagnostic: 3) or just modify the existing error with the proposed (so it looks like the 2 above). []:
Looks like current output already is an improvement over the reported one, but eithwr 2 or 3 would make it even more obvious i guess. No strong opinions here
Seems to me that the third error is the most clear ("error: missing in loop"); I suspect people using fancy pattern features will figure out what's going on.


Question: self.hir.span_bug(span, &format!("extent {:?} does not enclose", extent)) }); <ins> let tmp = self.get_unit_temp(); </ins> for (idx, ref scope) in self.scopes.iter().enumerate().rev().take(scope_count) { <del> unpack!(block = build_scope_drops(block, scope, &self.scopes[..idx], &mut self.cfg)); </del> <ins> unpack!(block = build_scope_drops(&mut self.cfg, scope, &self.scopes[..idx], block)); if let Some(ref free_data) = scope.free { let next = self.cfg.start_new_block(); let free = build_free(self.hir.tcx(), tmp.clone(), free_data, next); self.cfg.terminate(block, free); block = next; } </ins> } self.cfg.terminate(block, Terminator::Goto { target: target }); }

This generates the following (broken) MIR: As you can see, is dropped but never written to (AFAIK this should be OK because of zeroing) but the boxes are never freed.
cc
EDIT: I wasn’t looking closely enough, it is indeed broken.
This is a problem on latest master ()


Question: use crate::io; use crate::mem; <del> use crate::sync; </del> <ins> use crate::ptr; </ins> use crate::sys::c; <del> /// The kinds of HashMap RNG that may be available #[derive(Clone, Copy, Debug, PartialEq)] enum HashMapRng { Preferred, Fallback, } </del> pub fn hashmap_random_keys() -> (u64, u64) { <del> match get_hashmap_rng() { HashMapRng::Preferred => { preferred_rng().expect("couldn't generate random bytes with preferred RNG") } HashMapRng::Fallback => { fallback_rng().expect("couldn't generate random bytes with fallback RNG") } } } /// Returns the HashMap RNG that should be used /// /// Panics if they are both broken fn get_hashmap_rng() -> HashMapRng { // Assume that if the preferred RNG is broken the first time we use it, it likely means // that: the DLL has failed to load, there is no point to calling it over-and-over again, // and we should cache the result static VALUE: sync::OnceLock<HashMapRng> = sync::OnceLock::new(); *VALUE.get_or_init(choose_hashmap_rng) } /// Test whether we should use the preferred or fallback RNG /// /// If the preferred RNG is successful, we choose it. Otherwise, if the fallback RNG is successful, /// we choose that /// /// Panics if both the preferred and the fallback RNG are both non-functional fn choose_hashmap_rng() -> HashMapRng { let preferred_error = match preferred_rng() { Ok(_) => return HashMapRng::Preferred, Err(e) => e, }; match fallback_rng() { Ok(_) => return HashMapRng::Fallback, Err(fallback_error) => panic!( "preferred RNG broken: `{}`, fallback RNG broken: `{}`", preferred_error, fallback_error ), } } /// Generate random numbers using the preferred RNG function (BCryptGenRandom) fn preferred_rng() -> Result<(u64, u64), io::Error> { use crate::ptr; </del> let mut v = (0, 0); let ret = unsafe { c::BCryptGenRandom(

I tried this code: I expected it to work on Windows 7 the same as it works on other platforms. Instead, this happened: the code get stuck in the initialization of logging, we acquired same-ish stack from multiple people using Windows 7 It was always calling ! On Windows 10 as under Wine the application starts normally My rust code produces DLL that is loaded by C++ application from 10 years ago Latest working version: Earliest version that gets stuck:
seems possibly relevant, but since this is just hanging, I’m not sure we can blame it all on snake oil this time. Though maybe? Wouldn’t be the first time it breaks the system in incomprehensible ways. First and foremost – could you minimize the reproducer? Both from the perspective of the Rust code (sounds like simply calling from should suffice?) and the OS setup (does this occur on a fresh OS install? If not, what modifications are necessary for the reduced reproducer to start hanging)
The nightly that it first started failing under is the first nightly after was merged, which just happens to be directly related to ? That's really whack given that the stack trace above shows the hang taking place just before any of the changes that PR introduced are invoked.
I personally do not have Windows 7, and would prefer not not bother players with more testing unless really necessary. But I can confirm that at least one of the systems was clean Windows 7 Home Premium from . And calling directly seems pretty complicated :( It requires calling which still requires knowing which algorithm to chose, and what flags to use :( I also see this in the documentation: and this in the code: , but unfortunately I can not say how relevant that it.
It's unlikely to be a problem with itself as that works in the earlier version. Is this code being used in ? In any case, I think the fix here is to simplify the rng code so it's as close to the old version as possible.
Yes logging is initialized in DllMain, I will soon post a very small example
So it is related to it being library.


Question: use crate::io; use crate::mem; <del> use crate::sync; </del> <ins> use crate::ptr; </ins> use crate::sys::c; <del> /// The kinds of HashMap RNG that may be available #[derive(Clone, Copy, Debug, PartialEq)] enum HashMapRng { Preferred, Fallback, } </del> pub fn hashmap_random_keys() -> (u64, u64) { <del> match get_hashmap_rng() { HashMapRng::Preferred => { preferred_rng().expect("couldn't generate random bytes with preferred RNG") } HashMapRng::Fallback => { fallback_rng().expect("couldn't generate random bytes with fallback RNG") } } } /// Returns the HashMap RNG that should be used /// /// Panics if they are both broken fn get_hashmap_rng() -> HashMapRng { // Assume that if the preferred RNG is broken the first time we use it, it likely means // that: the DLL has failed to load, there is no point to calling it over-and-over again, // and we should cache the result static VALUE: sync::OnceLock<HashMapRng> = sync::OnceLock::new(); *VALUE.get_or_init(choose_hashmap_rng) } /// Test whether we should use the preferred or fallback RNG /// /// If the preferred RNG is successful, we choose it. Otherwise, if the fallback RNG is successful, /// we choose that /// /// Panics if both the preferred and the fallback RNG are both non-functional fn choose_hashmap_rng() -> HashMapRng { let preferred_error = match preferred_rng() { Ok(_) => return HashMapRng::Preferred, Err(e) => e, }; match fallback_rng() { Ok(_) => return HashMapRng::Fallback, Err(fallback_error) => panic!( "preferred RNG broken: `{}`, fallback RNG broken: `{}`", preferred_error, fallback_error ), } } /// Generate random numbers using the preferred RNG function (BCryptGenRandom) fn preferred_rng() -> Result<(u64, u64), io::Error> { use crate::ptr; </del> let mut v = (0, 0); let ret = unsafe { c::BCryptGenRandom(

It have something to do with initializing the logs in , but I have no clue what specific small detail it is that breaks it <details<summaryExe code (not much interesting)</summary<p</p</details<details<summaryDLL code</summary rust-toolchain </p</details
Ok, I've submitted a fix. See the PR linked above. is tricky because of the loader lock and other tricks the OS does while a dll is loading.
I know is tricky, but is there any better option to do initialization, if I do not control the exe? And I need to fix the exe (by doing memory patches) before it reaches its .
Possibly not, which is why I filed a fix. Using the std in only works on a "best effort" basis. We do try to support it as much as reasonably possible but there are always going to be limitations due to the OS.
I get maybe a bit crazy idea, but my DLL hooks functions anyway, so if I would limit to and before the hooked main do my initialization. (for my use case any time before main is good enough) Would that eliminate wast majority of potential breaks related to ? Or is it not worth it?
Calling load_library in is susceptible to deadlocks unless the library is already loaded. I think you might just need to be very careful about the dependencies you use. Maybe there's a different or lighter weight logger you can use in place of log4js that doesn't use HashSet?
On further inspection it seems unlikely that fixes the issue although I still think it's a good cleanup and simplification (so I stand by my r+). That is, looking at your back trace... the deadlock you're hitting is from inside BCryptGenRandom itself, not from our code that synchronizes while calling it. It looks like BCryptGenRandom does some synchronizing when getting the preferred RNG (I guess). My hunch is for whatever reason this ends up needing to take the loader lock, and because the loader lock is already held inside , this causes a deadlock. If this is the case, I don't think there's a way for us to solve it... we can't detect it this in advance, nor is there a good alternative approach we can take that doesn't make things worse when outside (and/or on newer systems, which apparently works?). So I'm not sure what we can do about this.