Question: // SAFETY: left and right must be valid and part of v same for out. unsafe { <del> let to_copy = if is_less(&*right, &**left) { get_and_increment(&mut right) } else { get_and_increment(left) }; ptr::copy_nonoverlapping(to_copy, get_and_increment(out), 1); </del> <ins> let is_l = is_less(&*right, &**left); let to_copy = if is_l { right } else { *left }; ptr::copy_nonoverlapping(to_copy, *out, 1); *out = out.add(1); right = right.add(is_l as usize); *left = left.add(!is_l as usize); </ins> } } } else {

I tried this code, sorting 30 million random : On this machine: Using the vendored version of from mid 2022 see here I expected to see this happen: Runtime ~1.45s Instead, this happened: Runtime ~2s I bisected the issue down to with . The same happens if you do instead of . So this also affects the current implementation which is very similar to my vendored version.
Dinging into it, I think the relevant code that has this impact is in the function. Which has two blocks of logic one for if the left side is shorter and one if the right side is shorter. Previously both sides generated code that is branchless in terms of jumping based on the comparison result. Now the block handling left side is shorter generates a jump based on the comparison result. LLVM 15: ! LLVM 16: ! This can be fixed in code by using 'proper' branchless code: -This would fix the stdlib, but it would still mean a regression for any other code out there that relies on this.
I feel like I should attach the usual disclaimer that this kind of optimization can never be considered fully stable, specifically LLVM has various heuristics that affect whether it compiles a segment of code to use a "branchless" CMOV-alike or use a jump, however that doesn't mean there's nothing we can do here. label: +A-LLVM +A-codegen +regression-from-stable-to-beta +I-slow
WG-prioritization assigning priority (). label -I-prioritize +P-low +T-compiler
out of curiosity. What is the future for a perf regression marked as P-low? Is there any work planned on this? Personally I was surprised that it even generated branchless code in the first place.
A P-high or P-critical compiler issue means that it will be reviewed regularly by T-compiler until it is resolved, where "regularly" is a much higher frequency for P-critical. So a P-low implicitly means "this isn't so important that we need to keep putting it on the agenda". Though I should note that periodically, all T-compiler issues do get reviewed and triaged, just on a more irregular basis.


Question: // SAFETY: left and right must be valid and part of v same for out. unsafe { <del> let to_copy = if is_less(&*right, &**left) { get_and_increment(&mut right) } else { get_and_increment(left) }; ptr::copy_nonoverlapping(to_copy, get_and_increment(out), 1); </del> <ins> let is_l = is_less(&*right, &**left); let to_copy = if is_l { right } else { *left }; ptr::copy_nonoverlapping(to_copy, *out, 1); *out = out.add(1); right = right.add(is_l as usize); *left = left.add(!is_l as usize); </ins> } } } else {

Performance work is one of those "never done" things so it's rare for it to be high priority in general, which isn't the same as "no one will work on it". It just means it would be addressed in a somewhat irregular fashion.
I'm not sure I understand the difference between "never done" and "no one will work on it".
"Never done" as in "never finished" not "never worked on"
Ohh, thanks for clarifying. Anyway from my perspective me and other people I've talked to were surprised this even generated branchless code in the first place, I'd be fine with closing this issue as won't fix.
since you have opened a PR (thanks a lot for that!), it makes totally sense to try fixing it, no matter the priority we assign to issues.
I think the issue can be split into two parts: A) A significant regression in . B) LLVM no longer generating branchless code for a certain pattern. I think A should definitely be fixed, and that's what my PR is for. B however I'd argue doesn't really need fixing, because the code in question was not obviously branchless.


Question: )]; let mut has_unsized_tuple_coercion = false; <del> let mut has_trait_upcasting_coercion = false; </del> <ins> let mut has_trait_upcasting_coercion = None; </ins> // Keep resolving `CoerceUnsized` and `Unsize` predicates to avoid // emitting a coercion in cases like `Foo<$1>` -> `Foo<$2>`, where

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --It should name the traits are attempted to be coerced, maybe tell me why that's not allowed (yet), etc. Right now it just highlights the entire line. The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed". Note that I understand why it's not allowed, I was just disappointed by the error message. I already talked to about this, and they also thought this output may be problematic. Even though the feature may be unstable, it's quite easy to arrive at a situation where you may get this error. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: // More information on the environment variable is available here: // https://www.gnu.org/prep/standards/html_node/DESTDIR.html if let Some(destdir) = env::var_os("DESTDIR").map(PathBuf::from) { <ins> // Sanity check for the user write access on DESTDIR assert!(is_dir_writable_for_user(&destdir), "User doesn't have write access on DESTDIR."); </ins> let without_destdir = path.clone(); path = destdir; // Custom .join() which ignores disk roots.

In the followup discussion on , we discovered that their original problem was because they had chosen a path under their home directory for , but they had not changed the default . So most things installed fine, but they didn't have permission to write . Bootstrap could sanity check this when starting an install, seeing that is writable by the current user but the absolute is not. (A relative goes under , which should be fine.) This should also take into account as a further prefix on all installation paths.
I have just updated to version 1.71.0, and now I'm receiving the terminal warning: In my previous setup, I the line to my file.
yeah, made that effectively . That was reverted in , and now proposed for stable and beta backports. So you could add for now, but it will be going back to the way it was.


Question: # "-C", "linker=arm-none-eabi-gcc", # "-C", "link-arg=-Wl,-Tlink.x", # "-C", "link-arg=-nostartfiles", <del> ] </del>  No newline at end of file <ins> ] </ins>

I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.


Question: if x == 0.0 { 0 } else { 1 } } <ins> pub fn bitwise_not() -> i32 { // CHECK-LABEL: fn bitwise_not( // CHECK: switchInt( // Test for #131195, which was optimizing `!a == b` into `a != b`. let mut a: i32 = 0; a = 1; if !a == 0 { 1 } else { 0 } } </ins> fn main() { // CHECK-LABEL: fn main( too_complex(Ok(0));

<!-- 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: always panic Instead, this happened: only -Zmir-opt-level=2 panic For mir-opt-level 0, 1 and 3, they all normally return <!-- 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 --<!-- TRIAGEBOTEND --
equals , so I think the panic case is incorrect?
Yeah, I think so.
Looks like it's JumpThreading that incorrectly removes the condition
I managed to create an example without panic, just wrong value
Most likely
ha, I found the bug. We're optimizing incorrectly in the jump threading code. Right now it's only written to handle bool correctly. I'll put up a fix claim


Question: None, ); if let Some(infer::RelateParamBound(_, t, _)) = origin { <del> let return_impl_trait = self.tcx.return_type_impl_trait(generic_param_scope).is_some(); </del> let t = self.resolve_vars_if_possible(t); match t.kind() { // We've got: // fn get_later<G, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ // suggest: // fn get_later<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a <del> ty::Closure(..) | ty::Alias(ty::Opaque, ..) if return_impl_trait => { </del> <ins> ty::Closure(..) | ty::Alias(ty::Opaque, ..) => { </ins> new_binding_suggestion(&mut err, type_param_span); } _ => {

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: <ins> error[E0046]: not all trait items implemented, missing: `Error`, `try_from` --> $DIR/issue-74047.rs:14:1 | LL | impl TryFrom<OtherStream> for MyStream {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `Error`, `try_from` in implementation | = help: implement the missing item: `type Error = Type;` = help: implement the missing item: `fn try_from(_: T) -> std::result::Result<Self, <Self as std::convert::TryFrom<T>>::Error> { todo!() }` error: aborting due to previous error For more information about this error, try `rustc --explain E0046`. </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. --produces an ICE for the code given below. This code should produce an error (the implementation is missing associated items). (UPDATED: Here's MCVE: ) <!-- 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. --: Error also occurs 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
Thanks! Further minimized:
Assigning as and removing .
Don't know the cause yet, but if you remove the keyword or the operator, then you get this error: My hunch is that somehow, lacking those items, the type of is coming up with something that doesn't implement the expected traits -- I would bet that we are getting an , based on some of the output at the end. Perhaps some of the logic in MIR is failing as a result. The actual ICE location though isn't that illuminating:
I did some digging here. The source of the panic is here, during HAIR construction: In this case, the binding below is of the error type (meaning type check for it failed). By replacing the binding with `` we prevent a local from being created for it, which means that when we try to generate code that reads the local we get a panic . I'm not sure what the correct fix is here. Replacing the binding with was done to prevent other ICEs, but we can't generate valid MIR without the local info. More fundamentally: We're building MIR during typeck because this is an async fn. In the past we probably never would have gotten to this stage. Backtrace: <details</details


Question: // Since this is a return parameter type it is safe to unwrap. let ret_param_ty = projection.skip_binder().term.expect_type(); <del> let ret_param_ty = self.resolve_vars_if_possible(ret_param_ty); </del> debug!(?ret_param_ty); let sig = projection.rebind(self.tcx.mk_fn_sig(

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


Question: gate_feature_post!(&self, generic_associated_types, ti.span, "generic associated types are unstable"); } <ins> if !ti.generics.where_clause.predicates.is_empty() { gate_feature_post!(&self, generic_associated_types, ti.span, "where clauses on associated types are unstable"); } </ins> } _ => {} }

clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24


Question: let path = match bounds.remove(0) { GenericBound::Trait(pt, ..) => pt.trait_ref.path, GenericBound::Outlives(..) => { <del> self.span_bug(ty.span, "unexpected lifetime bound") </del> <ins> return Err(self.struct_span_err( ty.span, "expected trait bound, not lifetime bound", )); </ins> } }; self.parse_remaining_bounds(Vec::new(), path, lo, true)

I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
triage : P-medium, removing nomination, adding needs-bisect.
(the bisection here would be entirely automatable if were addressed.)
Bisected roughly: ICE occurred from but not panicked, panicked from
in particular looks suspicious. cc
Pre-, we return early with an error here: Post-, in the corresponding code happens in a call to : and the parser "recovers" from the error encountered in , allowing this line to be reached:
I opened , which takes the stance that is no longer appropriate here. It's possible that there's a better fix that changes the way works, but that would require a deeper expertise of how these things are supposed to work than I currently have.


Question: // memory, which makes for some *confusing* logs. That's why these are here // instead of in std. <del> #![reexport_test_harness_main = "test_main"] </del> #![feature(libc, std_misc, duration)] extern crate libc;

While trying to figure out what the attribute did, I ran across this line of code. Near as I can tell, the reference to here doesn't do anything, and can be removed for clarity.
Marking as an easy issue since it seems that removing that line is all that would need to be done here, and then if CI passes, great, if not, then we shouldn't remove it. Willing to mentor as well.
I take this up
close?


Question: <ins> trait PrivateTrait { const FOO: usize; } </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. --the minimal triggering case seems to impl a trait that isn't visible from the location it ends up. edit: this turns out not to require macros at all. <!-- 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. --: This also occurs in nightly (), but not in stable (which provides the correct complaint that is not publicly re-exported) <!-- 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 --
searched nightlies: from nightly-2023-11-11 to nightly-2023-12-28 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
0x7f6adfe7f645 - core::panicking::panic fmt::hcc at /rustc/ /library/core 72:14 180 x - <rustc resolve[]::late ::LateResolutionVisitor as rustcast[]::visit::Visitor::visititem 19: 0x7f6adee2d7ff - <rustcresolve[]::Resolver::resolvecrate ::{closure} 20: 0x7f6adee2ad1a - <rustcresolve[]::Resolver::resolvecrate 21: 0x7f6adeeb6d72 - rustcinterface[]::passes::resolverforlowering 22: 0x7f6adeeb5e2b - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::resolverforlowering::dynamicquery::{closure}::{closure},


Question: <ins> trait PrivateTrait { const FOO: usize; } </ins>

rustcmiddle[]::query::erase::Erased<[u8; 8usize]23: 0x7f6adef1f8ec - rustcquerysystem[]: :query::plumbing::tryexecutequery::<rustcquery impl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, true24: 0x7f6adef1eff3 - rustcqueryimpl[]::queryimpl::resolverforlowering::getqueryincr::rustendshortbacktrace 25: 0x7f6aded0bab3 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 26: 0x7f6adee3b25b - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed27: 0x7f6adee3b0b9 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 28: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,


Question: <ins> trait PrivateTrait { const FOO: usize; } </ins>

Aas core::ops::function::FnOnce<Args::callonce::h5d7c8f150ab9c84c at 29: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::h570d5b005c242c15 at 30: 0x7f6adfe3d8e5 - std::sys::unix::thread::Thread::new::threadstart::h36b0a20c0b2361ad at 31: 0x7f6ad9e97ada - <unknown32: 0x7f6ad9f2847c - <unknown33: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.76.0-beta.1 ( 2023-12-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type bin -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED] note: some of the compiler flags provided by cargo are hidden query stack during panic: [resolverfor_lowering] getting the resolver for lowering end of query stack
That is line 18 to 33
WG-prioritization assigning priority (). label -I-prioritize +P-medium
An interesting issue, claim
interesting that the crash also doesn't happen if we qualify the trait with instead of the crate's name.
The is interpreted as referring to an external crate, whereas not
right; i'm assuming it hits a different resolver codepath, despite both working the same if the referred ident is public. thanks for the quick fix!


Question: <ins> // Test a method call where the parameter `B` would (illegally) be // inferred to a region bound in the method argument. If this program // were accepted, then the closure passed to `s.f` could escape its // argument. //@ run-rustfix struct S; impl S { fn f<B, F>(&self, _: F) where F: FnOnce(&i32) -> B { } } fn main() { let s = S; s.f(|p| *p) //~ ERROR lifetime may not live long enough } </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'', 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [mirborrowck] borrow-checking --
ICEs on nightly and beta, but not on stable. Minimized further: <details<summaryProgram output</summary</details
The ICE is another one from , cc
Still reproduces on 1.81.0-nightly (2024-06-13 ) -E-needs-test
I'll look into it later today.


Question: <ins> // Test a method call where the parameter `B` would (illegally) be // inferred to a region bound in the method argument. If this program // were accepted, then the closure passed to `s.f` could escape its // argument. //@ run-rustfix struct S; impl S { fn f<B, F>(&self, _: F) where F: FnOnce(&i32) -> B { } } fn main() { let s = S; s.f(|p| *p) //~ ERROR lifetime may not live long enough } </ins>

: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.


Question: trait_def_id, ty, params, param_env ); <del> // Do not check on infer_types to avoid panic in evaluate_obligation. if ty.has_infer_types() { return false; } let ty = tcx.erase_regions(&ty); </del> let trait_ref = ty::TraitRef { def_id: trait_def_id, substs: tcx.mk_substs_trait(ty, params) }; let obligation = Obligation {

<!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc


Question: <ins> //@ check-pass #![feature(adt_const_params)] // Regression test for #116308 pub trait Identity { type Identity; } impl<T> Identity for T { type Identity = Self; } pub fn foo<const X: <i32 as Identity>::Identity>() {} fn main() { foo::<12>(); } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2023-06-03 Regression in Regression in ?
This is fixed by .
assign


Question: name: FieldName) { let fields = ty::lookup_struct_fields(self.tcx, id); let field = match name { <del> NamedField(ident) => { debug!("privacy - check named field {} in struct {:?}", ident.name, id); fields.iter().find(|f| f.name == ident.name).unwrap() </del> <ins> NamedField(f_name) => { debug!("privacy - check named field {} in struct {:?}", f_name, id); fields.iter().find(|f| f.name == f_name).unwrap() </ins> } UnnamedField(idx) => &fields[idx] };

Tracking issue for: rust-lang/rfcs Functional record update does not mark the source as consumed, even if does not implement Copy. This means that e.g. the source's destructor will eventually be run, so the following code prints :
Note that, as discovered, you can also explicitly consume , also allowing code like:
:bomb:
Is legal, even if all members are private? It's a bit surprising
It is. There's the potentially-useful case where some of the members are private, and FRU allows you to update the public ones. Of course it should consume the source even then.
P-backcompat-lang, 1.0 beta
In my opinion the problem here is the privacy violation. The idea is that is expanded to and so forth. In this case, that does not trigger a move, because the types of those fields are . I think that part is acting as expected. What is surprising is that one can do this from outside the module.
That was (but my favored solution isn't minor).
When I initially saw this problem, I did not see it as a privacy violation, for the (obvious?) reason that since no private members of had been mentioned in the code , the client module is not breaking any abstraction introduced by privacy. I think this line of thinking is analogous to outline of the useful case where FRU allows one to update the public members of a type and silently move the private ones as well, via . This is useful for the case where the author of wants to reserve the right to add new private members to while still allowing for clients to use the convenient FRU syntax. I originally was going to try to explain my point of view via analogy with something from hygienic macros: If I were to define (and export) a macro within 's defining module: then it should, in principle, not be a privacy violation to use from client code outside 's defining module. (That is, in principle, hygiene should allow macros to expose controlled access to private internals.) Then I realized the crucial problem with that kind of analogy: is something that the designer of has to choose to put into the module; i.e., it is opt-in. But currently in Rust, FRU is not opt-in; its not even something you can opt out of.


Question: name: FieldName) { let fields = ty::lookup_struct_fields(self.tcx, id); let field = match name { <del> NamedField(ident) => { debug!("privacy - check named field {} in struct {:?}", ident.name, id); fields.iter().find(|f| f.name == ident.name).unwrap() </del> <ins> NamedField(f_name) => { debug!("privacy - check named field {} in struct {:?}", f_name, id); fields.iter().find(|f| f.name == f_name).unwrap() </ins> } UnnamedField(idx) => &fields[idx] };

Any struct automatically is given support for it, whether it be appropriate for that struct or not. And that seems wrong, at least given examples like the one provided here in . This latter point, that providing support for FRU should not be something that is silently attached to a type like , seems somewhat in line with the thinking given in . But I am also pretty sure we cannot adopt anything of the scope given in that draft. (Still, maybe there's a hint of solution embedded within, in the sense of having some way of marking a type as data vs abstract; see final two bullet points below.) So, as I see it, we can either: out a way to support the point-of-view outlined here in the description for , in that should somehow be treated as consuming . Such a change seems like it would be quite subtle, since we would need to have some way of expressing that code like is sound, even if the types of the fields and are consumed by their respective and methods. (In other words, need to consume , yet somehow not completely consume it. Maybe there's a way to think of it as consuming "whatever is left of the type", I do not know.) Advantages: This would address the bug as described by the issue author, and would not break any code that was not already broken. Drawbacks: It is not clear what the semantics are for this form (in other words: the phrase "would not break any code" above is only true if you first accept that this hypothesized semantics exists). Also, there may not be time to do this properly for 1.0. , try to adopt a data/abstract-type distinction along the lines of the one in draft RFC. (I'm not going to write Advantages/Drawbacks for this; I think we clearly do not have time to do it that way for 1.0) , change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks. Advantages: Seems really simple to implement, and is consistent with at least one core team member's mental model of FRU. Drawbacks: If we did this, then code like the example above would break.


Question: name: FieldName) { let fields = ty::lookup_struct_fields(self.tcx, id); let field = match name { <del> NamedField(ident) => { debug!("privacy - check named field {} in struct {:?}", ident.name, id); fields.iter().find(|f| f.name == ident.name).unwrap() </del> <ins> NamedField(f_name) => { debug!("privacy - check named field {} in struct {:?}", f_name, id); fields.iter().find(|f| f.name == f_name).unwrap() </ins> } UnnamedField(idx) => &fields[idx] };

, let FRU keep its current hygienic (aka "privacy violating") semantics, but also make FRU something one must opt-in to support on a type. E.g. make a builtin trait that a struct must implement in order to be usable with FRU. (Or maybe its an attribute you attach to the item.) Advantages: Also seems really simple to implement (in the language). Accommodates users of FRU for the example. Drawbacks: If we did this, it would impose a burden on all code today that makes use of FRU, since they would have to start implementing . Thus, not simple to implement for the libraries and the overall ecosystem. , a hybrid between the previous two bullet-points: By default, treat FRU as non-hygienic expansion, but add a builtin trait that one can opt-into to get the hygienic (aka "privacy violating") semantics. As a bonus, perhaps implementing on a struct would also imply implementing on that struct, which seems like it would basically give us something very similar to the semantics desired by (Or, again, maybe its an attribute you attach to the item. This detail does not particularly matter to me.) Advantage: While this is obviously more complicated than the previous two bullet-points, it has the advantage that it has a staged landing strategy: We could just_ implement the change to FRU to be non-hygienic expansion for 1.0 beta. We could add at an arbitrary point in the future; it would not have to be in the 1.0 release. Drawback: People have claimed that some of my past proposals were a bit ... baroque. I imagine this one is no exception. :) (In other words, this semantics is a little complicated to explain to a newcomer.)
I don't want to make a big fuss about it, but I do want to note, again, that our "deadlines" are entirely self-imposed, and that under these circumstances "we don't have time" is slightly odd, because we can make time, any time we want. The blanket refusal to even contemplate doing that - even in light of new information - and to weigh the tradeoffs on their own merits is something I still don't really understand.


Question: name: FieldName) { let fields = ty::lookup_struct_fields(self.tcx, id); let field = match name { <del> NamedField(ident) => { debug!("privacy - check named field {} in struct {:?}", ident.name, id); fields.iter().find(|f| f.name == ident.name).unwrap() </del> <ins> NamedField(f_name) => { debug!("privacy - check named field {} in struct {:?}", f_name, id); fields.iter().find(|f| f.name == f_name).unwrap() </ins> } UnnamedField(idx) => &fields[idx] };

That out of the way, an additional possibility, let's call it 6., for list: We could just make the "abstract type" vs. "data type" distinction based on "does or doesn't the type have a private field". This doesn't entirely fill me with satisfaction (as with "worse is better" solutions in general), with specific drawbacks being that it doesn't extend cleanly to the nullary case (no fields at all), and that in terms of UX a change of semantics based on the presence or absence of a private field may be unexpected, but on the plus side, it's simpler, and would, I think, work.
Sure, hypothetical show-stopper issues could cause us to revisit our self-imposed schedule. I personally don't think that this issue, on its own at least, provides sufficient motivation for schedule revision. I admit that your draft RFC seems like it addresses a host of issues, so maybe all of them taken in unison would be a different story. (But then again, that's not even my call to make.)
There were a couple more options that I should have put on the list, for completeness, but overlooked. 6 note, the "has any private fields ==abstract-type; all public fields ==data-type", is one of them. This would (probably) be less work than adopting the draft RFC in full, but I am not sure what the other Advantages/Disadvantages are. I invite others to write an Advantages/Drawbacks for this approach (perhaps in an RFC PR). 7 We could add a way for a struct to opt-out of FRU support entirely. So in this approach, one would attach the appropriate attribute to , , etc. Advantages: won't break any existing code Drawbacks: Seems quite fragile; we may be good about auditing our own stdlib, but clients who are not aware of the attribute may inadvertently expose themselves to the same bug that currently plagues .
Also, I just wanted to mention: when I wrote my comment 6 hours ago, I came to the keyboard thinking that the FRU support for adding new private fields to and having still work was an important use case. But after some reflection in the hours since, supporting that use case does not seem as important to me.


Question: name: FieldName) { let fields = ty::lookup_struct_fields(self.tcx, id); let field = match name { <del> NamedField(ident) => { debug!("privacy - check named field {} in struct {:?}", ident.name, id); fields.iter().find(|f| f.name == ident.name).unwrap() </del> <ins> NamedField(f_name) => { debug!("privacy - check named field {} in struct {:?}", f_name, id); fields.iter().find(|f| f.name == f_name).unwrap() </ins> } UnnamedField(idx) => &fields[idx] };

Here is why: It is relatively easy for a developer who wants to provide that sort of extensible abstraction can still do it, by factoring the type into a all-public front-end with a single public field that holds the all-private back-end, like so: So, given that there exists a reasonable pattern to bring back usable FRU even under the option "(3.) change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks.", I would not object to us adopting (3.) aka solution.
I think that "has any private field" is a decent way to handle abstractness (you can always add a private unit field). On the other hand, Rust supports trait bounds of types – these should handle roles just fine – you shouldn't be able to coerce past a trait bound. By the way, this is somewhat subtle, because coercing to is wrong (as it leaks memory – it coerces past the implicit bound), but coercing to is fine (as the bound isn't used by ). However, this isn't a property of – you still can't coerce to – so we probably want a relatively-sophisticated way to occasionally ignore roles.
I mean, Rust already has a mechanism for ensuring representation-abstraction – private fields – which are semantic (they are handled after type-checking, we probably want to handle them during it, but they definitely aren't handled syntactically or during resolution). It is just that FRU currently accesses them improperly. Also, it doesn't have much to do with e.g. roles – is an abstract type, but it doesn't use any bound on . only uses the implicit bound. A for data-only types would be nice, through.
Another alternative came to me while I was drafting an RFC about this. (But its an alternative that I do not particularly like.) 8a Instead of making "has any private fields" the thing that makes FRU unavailable, instead make the rule be "has all private fields." Thus types like and will not be subject to the vulnerability outlined here. Adding a single field to an otherwise private struct is what changes the nature of a struct with respect to abstraction and FRU, rather than adding a single non- field to an otherwise public struct.


Question: name: FieldName) { let fields = ty::lookup_struct_fields(self.tcx, id); let field = match name { <del> NamedField(ident) => { debug!("privacy - check named field {} in struct {:?}", ident.name, id); fields.iter().find(|f| f.name == ident.name).unwrap() </del> <ins> NamedField(f_name) => { debug!("privacy - check named field {} in struct {:?}", f_name, id); fields.iter().find(|f| f.name == f_name).unwrap() </ins> } UnnamedField(idx) => &fields[idx] };

8b, which is so similar to 8a that I gave them both the same numeral: Outlaw the trivial FRU form . That is, to use FRU, you have to use at least one field in the constructing expression. Again, this implies that types like and will not be subject to the vulnerability outlined here. (This may be a decent change to make to the language regardless of whatever else happens on this ticket; the only argument in favor of keeping support for such a trivial form is maybe for supporting certain macro-expansions. But fully-general macro-authors already have to tread very carefully around corner cases on structs, due to issues like the empty braces problem (see )
That would leave the vulnerability intact in the case where the type has both public fields and private fields, the fact that no such type currently exists in the standard library notwithstanding (just as a very artificial demonstration, consider a with ).
yep. Library authors would have to factor their structures very carefully. (I described the drawback you mention in the RFC I posted shortly after you wrote your comment, though I did not include the detail of having the private fields be , which does seem like it could make the situation all the more subtle. Not insurmountable, but a definite drawback.) Just to be clear, I'm not saying I prefer (8a) or (8b); I'm just trying to be complete in my exploration of the solution space.
Repurposed as the tracking issue for rust-lang/rfcs
I'll just go snag


Question: // the specialized routine `ty::replace_late_regions()`. match *r { ty::ReEarlyBound(data) => { <del> let r = self.substs.get(data.index as usize).map(|k| k.unpack()); match r { </del> <ins> let rk = self.substs.get(data.index as usize).map(|k| k.unpack()); match rk { </ins> Some(UnpackedKind::Lifetime(lt)) => { self.shift_region_through_binders(lt) } _ => { let span = self.span.unwrap_or(DUMMY_SP); <del> span_bug!( span, </del> <ins> let msg = format!( </ins> "Region parameter out of range  when substituting in region {} (root type={:?})  (index={})", data.name, self.root_ty, data.index); <ins> self.tcx.sess.delay_span_bug(span, &msg); r </ins> } } }

The following minimal example causes an internal compiler error. Error in question: rustc version: This error was encountered on stable, but I can confirm that it also occurs on the latest nightly ().
Hasn't the feature gate issue been fixed? :|
I've removed the nomination and this to the tracking issue for GATs . The current impl is highly incomplete and ICEs are, sadly, expected. Also, I verified that a feature gate is indeed required.
triage: P-medium
I don't know if I get you wrong, but the example above ICEs on stable, beta and nightly without feature gate
oops, looks like I accidentally left the feature gate in there when I tried it out, but it produces the same ICE when it is omitted as well.
No, niko edited your question. ping I think you got something wrong there. Can you please clarify that?
Oh, I guess I was indeed incorreect. I tried it on play but didn't notice that, after the "correct" error, it goes on to print an ICE.
What about adding the I-nominated tag again?
I'm not sure why we would nominate this for discussion. Yes, it is an ICE (and an ICE that occurs without the user adding a feature gate), but the message pretty clearly states that you're using an unstable feature. It would be great to fix it so that it issues the error diagnostic without ICEing, but I wouldn't re-prioritize that work above P-medium.
assigning to self since its a clear annoyance
triage: P-medium. (dupe of )
(the remaining bug, when the feature gate is enabled, is tracked in issue )


Question: def gh_url(): <ins> # type: () -> str </ins> return os.environ['TOOLSTATE_ISSUES_API_URL'] def maybe_delink(message): <ins> # type: (str) -> str </ins> if os.environ.get('TOOLSTATE_SKIP_MENTIONS') is not None: return message.replace("@", "") return message

Updated the toolstate repository at https://rust-lang- currently does not seem to work, see e.g. To "tool failed to build"-issues are being created, either. remarked that the error . Cc


Question: //~ TRANS_ITEM fn instantiation_through_vtable::{{impl}}[0]::bar[0]<u64> let _ = &s1 as &Trait; } <del> //~ TRANS_ITEM drop-glue i8 </del>

I found that current rustc 1.13.0-nightly can't compile'Rust by Example - 8.2.5 As output parameters' code, both on my linux pc and . I tried this code: see Executing code above on Rust Playground produces the message below when selecting nightly. ( but stable and beta do not produce this error). error: linking with failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib" "./out.0.o" "-o" "./out" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libstd-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libpanicunwind-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libunwind-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/librand-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libcollections-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/librustcunicode-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liballoc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liballocjemalloc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liblibc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libcore-" "-l" "dl" "-l" "pthread" "-l" "gccs" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt" = note: ./out.0.o: In function drop::hf3564cae7b79f1cb': (.text.


Question: //~ TRANS_ITEM fn instantiation_through_vtable::{{impl}}[0]::bar[0]<u64> let _ = &s1 as &Trait; } <del> //~ TRANS_ITEM drop-glue i8 </del>

ZN4drop17hf3564cae7b79f1cbE+0xd): undefined reference toLTGTasGT$::drop::h4c07c16183524d21' ./out.0.o: In function drop::hc5f0e028c3876d25': (.text.ZN4drop17hc5f0e028c3876d25E+0xd): undefined reference toLTGTasGT$::drop::h7a8bb753832b1af2' collect2: error: ld returned 1 exit status error: aborting due to previous error Compilation failed. This happens on my Linux Laptop pc as well. This is my laptop's rustc version(installing current latest) . : rustc 1.13.0-nightly ( 2016-08-25) binary: rustc commit-hash: commit-date: 2016-08-25 host: x86_64-unknown-linux-gnu release: 1.13.0-nightly
Nominating since this appears to be a regression.
is still good, does not exist and fails. . Reduced:
This may be a related to . Edit: not a duplicate I think, since was introduced in a different nightly.
Running with the above sample and leads to an ICE in printing a log message
This is from the removal of old trans. We should've been covered by on-demand drop glue generation still, though. cc
Looking at the IR - the missing methods are d, and called from drop methods taking e.g.
Oh, this is bad. The collector needs to know user definitions being instantiated ahead of time (including impls), and these can be used from drop glue which is not guaranteedly known ahead of time. We might need to temporarily detect the shim'd cases in the collector and trigger drop glue generation. cc
I'm looking into a short-term fix right now.
yay! Thanks


Question: .and_then(|ur_vid| self.definitions[*ur_vid].external_name) .unwrap_or(infcx.tcx.lifetimes.re_root_empty), ty::ReLateBound(..) => region, <ins> ty::ReStatic => region, </ins> _ => { infcx.tcx.sess.delay_span_bug( span,

Trying to build  0.2.5 with latest nightly results in an ICE. Bisected the regression to , cc I have tried to minimize it. This still requires 0.3, I'm not sure how to minimize if further. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Seems like a duplicate of
I don't think that is related, neither the error matches nor is it a recent regression. Did you link the wrong issue? fixes this ICE
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Still needs a backport
(assigning self to ensure backport happens.)
Also seen in the latest (): zebra-consensus: https://crater- warp v0.3.1: https://crater- linkerd: https://crater- Along with a number of others.
Backport () was merged.


Question: <ins> //@ check-pass #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use pub fn y<'a, U: 'a>() -> impl IntoIterator<Item = impl IntoIterator<Item = [u8; { 1 + 2 }]> + 'a> { [[[1, 2, 3]]] } // Make sure that the `predicates_of` for `{ 1 + 2 }` don't mention the duplicated lifetimes of // the *outer* iterator. Whether they should mention the duplicated lifetimes of the *inner* // iterator are another question, but not really something we need to answer immediately. fn main() {} </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: <ins> //@ check-pass #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use pub fn y<'a, U: 'a>() -> impl IntoIterator<Item = impl IntoIterator<Item = [u8; { 1 + 2 }]> + 'a> { [[[1, 2, 3]]] } // Make sure that the `predicates_of` for `{ 1 + 2 }` don't mention the duplicated lifetimes of // the *outer* iterator. Whether they should mention the duplicated lifetimes of the *inner* // iterator are another question, but not really something we need to answer immediately. fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.


Question: <ins> error: arbitrary expressions aren't allowed in patterns --> $DIR/expr_before_ident_pat.rs:12:12 | LL |     funny!(a, a); |            ^ error[E0425]: cannot find value `a` in this scope --> $DIR/expr_before_ident_pat.rs:12:12 | LL |     funny!(a, a); |            ^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

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


Question: { <del> "data-layout": "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-f80:32-n8:16:32-S128", </del> <ins> "data-layout": "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i128:128-f64:32:64-f80:32-n8:16:32-S128", </ins> "linker-flavor": "gcc", "llvm-target": "i686-unknown-linux-gnu", "target-endian": "little",

The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.


Question: where L: HasLocalDecls<'tcx>, { <del> for (place_base, elem) in place.iter_projections().rev() { match elem { // encountered a Deref, which is ABI-aligned ProjectionElem::Deref => break, ProjectionElem::Field(..) => { let ty = place_base.ty(local_decls, tcx).ty; match ty.kind() { ty::Adt(def, _) => return def.repr().pack, _ => {} } } _ => {} } } None </del> <ins> place .iter_projections() .rev() // Stop at `Deref`; standard ABI alignment applies there. .take_while(|(_base, elem)| !matches!(elem, ProjectionElem::Deref)) // Consider the packed alignments at play here... .filter_map(|(base, _elem)| { base.ty(local_decls, tcx).ty.ty_adt_def().and_then(|adt| adt.repr().pack) }) // ... and compute their minimum. // The overall smallest alignment is what matters. .min() </ins> }

I tried this code: I expected to see this happen: The reference is aligned Instead, this happened: : label I-unsound A-mir
We have a pass to add moves for drops in packed structs, but it doesn't fire in this case. That's because there's a bug - this computation cannot just take into account the innermost field, it needs to compute a minimum of some sort.
is this a regression? What did you exactly expected the output to be? (I'd like to run a bisection). thanks.
This was right in . Getting a consistent reproduction of this is slightly difficult because the reference might happen to align correctly by accident. In other words, the fact that the example above prints a pointer that is not 2-aligned means that something is certainly wrong. However, if the address were to be 2-aligned that could either be because the bug is fixed or because we happened to get lucky. The consistent way to check this is by looking at . In 1.52.0 the MIR contains which is correct (the move ensures that the resulting place is aligned) while 1.53.0 contains Note that there is no move.
WG-prioritization assigning priority (). label -I-prioritize +P-high E-needs-bisection
I have run a bisection with on your . The bisection could not pinpoint a single commit, maybe it sinked into a rollup merge. But if it helps, the regression should be in and coming from one of these PRs do you see in any of those a possible culprit? (I don't have the context to)
Yeah, it's , cc
Not sure how would have an effect here, it should be a NOP for with . Looks like something else is amiss as well and that PR surfaced the bug? Where is the logic that moves packed structs to a new place before dropping implemented? That's odd, I would have expected this to be inside ... after all calling on a packed struct also has to do this move. Why does MIR building adjust the caller to satisfy a requirement that the callee should be responsible for?
the pass is called or something like that.


Question: where L: HasLocalDecls<'tcx>, { <del> for (place_base, elem) in place.iter_projections().rev() { match elem { // encountered a Deref, which is ABI-aligned ProjectionElem::Deref => break, ProjectionElem::Field(..) => { let ty = place_base.ty(local_decls, tcx).ty; match ty.kind() { ty::Adt(def, _) => return def.repr().pack, _ => {} } } _ => {} } } None </del> <ins> place .iter_projections() .rev() // Stop at `Deref`; standard ABI alignment applies there. .take_while(|(_base, elem)| !matches!(elem, ProjectionElem::Deref)) // Consider the packed alignments at play here... .filter_map(|(base, _elem)| { base.ty(local_decls, tcx).ty.ty_adt_def().and_then(|adt| adt.repr().pack) }) // ... and compute their minimum. // The overall smallest alignment is what matters. .min() </ins> }

And this can't take place inside the callee because the callee receives a , and if that reference is unaligned then UB has already occurred and there's nothing the callee can do to fix things anymore
takes a raw pointer, so it could very well be the place where the packed struct alignment trouble is handled. And IMO it'd be a much more natural place than doing this by transforming caller MIR.
I don't understand the suggestion. The example above never calls for a packed struct. The offending drop in the MIR in the example above is . The type of that place is - but if were to be responsible for moving, then we would need to emit a move in literally every drop shim for a non-trivial alignment type.
Oh I see, I didn't quite read the example correctly. The problematic drop is the one that happens on field assignment, and we know it's a packed field because of the path we are accessing it with. EDIT: no wait this makes no sense. Now I am confused by your comment.
No what I just said makes no sense. What happens is that this is a partial drop -- one field has been moved out () and then the logic for dropping the remaining fields seems to be wrong. So is relevant because it changed . And it looks like somehow the change is wrong; here is also despite the reference being unaligned.
should fix this.


Question: - name: install WIX run: src/ci/scripts/install-wix.sh if: success() && !env.SKIP_JOB <del> - name: install InnoSetup run: src/ci/scripts/install-innosetup.sh if: success() && !env.SKIP_JOB </del> - name: ensure the build happens on a partition with enough space run: src/ci/scripts/symlink-build-dir.sh if: success() && !env.SKIP_JOB

The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them.


Question: - name: install WIX run: src/ci/scripts/install-wix.sh if: success() && !env.SKIP_JOB <del> - name: install InnoSetup run: src/ci/scripts/install-innosetup.sh if: success() && !env.SKIP_JOB </del> - name: ensure the build happens on a partition with enough space run: src/ci/scripts/symlink-build-dir.sh if: success() && !env.SKIP_JOB

I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.


Question: // See the discussion in the stream implementation for why we we // might decrement steals. Some(data) => { <del> self.steals += 1; </del> if self.steals > MAX_STEALS { match self.cnt.swap(0, atomics::SeqCst) { DISCONNECTED => {

PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.


Question: <ins> // Copyright 2012 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. // Tests that the trait matching code takes lifetime parameters into account. // (Issue #15517.) struct Foo<'a,'b> { x: &'a int, y: &'b int, } trait Tr { fn foo(x: Self) {} } impl<'a,'b> Tr for Foo<'a,'b> { fn foo(x: Foo<'b,'a>) { //~^ ERROR method not compatible with trait //~^^ ERROR method not compatible with trait } } fn main(){} </ins>

The following code compiles: Nominating for 1.0, P-backcompat-lang. I may well just fix this along with , since the solution is likely going to be similar to what pointed out, but I want to get it on the radar.
Hmm, OK. So the code does attempt to handle this, but I don't know if it is handled in the right way. Specifically, it creates fresh region variables for each region and checks to see whether they unify. The trouble is that does unify with —it unifies if and only if and are the same region. But this is precisely what claimed to be a problem in . So I'm not sure what the right thing is to do here.
I'm going to assign to because I'm blocked on his opinion on what to do here.
Assigning P-backcompat-lang, 1.0.
Right thing to do is to use .
Argh. The right fix is to substitute some skolemized lifetimes in for the early bound regions before doing the unification rather than fresh variables.
Actually I think the problem is that we're just not calling on the inference context


Question: use super::{check_fn, Expectation, FnCtxt, GeneratorTypes}; use crate::astconv::AstConv; <del> use crate::middle::region; </del> <ins> use crate::middle::{lang_items, region}; </ins> use rustc::hir::def_id::DefId; use rustc::infer::{InferOk, InferResult}; use rustc::infer::LateBoundRegionConversionTime;

This somehow doesn't occur when putting the function in a non crate, yet I can't find any difference between the version of and this one. () Errors:
Seems like it panic when the trait is not found: Maybe it can use  instead.


Question: <del> error: the `wait` method cannot be invoked on a trait object --> $DIR/issue-35976.rs:14:9 | LL |         fn wait(&self) where Self: Sized; |                                    ----- this has a `Sized` requirement ... LL |     arg.wait(); |         ^^^^ error: aborting due to previous error </del>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.


Question: <del> error: the `wait` method cannot be invoked on a trait object --> $DIR/issue-35976.rs:14:9 | LL |         fn wait(&self) where Self: Sized; |                                    ----- this has a `Sized` requirement ... LL |     arg.wait(); |         ^^^^ error: aborting due to previous error </del>

(cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.


Question: Decl: Option<&'a DIDescriptor>, ) -> &'a DISubprogram; <ins> pub fn LLVMRustDIBuilderCreateMethod<'a>( Builder: &DIBuilder<'a>, Scope: &'a DIDescriptor, Name: *const c_char, NameLen: size_t, LinkageName: *const c_char, LinkageNameLen: size_t, File: &'a DIFile, LineNo: c_uint, Ty: &'a DIType, Flags: DIFlags, SPFlags: DISPFlags, TParam: &'a DIArray, ) -> &'a DISubprogram; </ins> pub fn LLVMRustDIBuilderCreateBasicType<'a>( Builder: &DIBuilder<'a>, Name: *const c_char,

If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim


Question: Decl: Option<&'a DIDescriptor>, ) -> &'a DISubprogram; <ins> pub fn LLVMRustDIBuilderCreateMethod<'a>( Builder: &DIBuilder<'a>, Scope: &'a DIDescriptor, Name: *const c_char, NameLen: size_t, LinkageName: *const c_char, LinkageNameLen: size_t, File: &'a DIFile, LineNo: c_uint, Ty: &'a DIType, Flags: DIFlags, SPFlags: DISPFlags, TParam: &'a DIArray, ) -> &'a DISubprogram; </ins> pub fn LLVMRustDIBuilderCreateBasicType<'a>( Builder: &DIBuilder<'a>, Name: *const c_char,

<!-- 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. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet.


Question: Decl: Option<&'a DIDescriptor>, ) -> &'a DISubprogram; <ins> pub fn LLVMRustDIBuilderCreateMethod<'a>( Builder: &DIBuilder<'a>, Scope: &'a DIDescriptor, Name: *const c_char, NameLen: size_t, LinkageName: *const c_char, LinkageNameLen: size_t, File: &'a DIFile, LineNo: c_uint, Ty: &'a DIType, Flags: DIFlags, SPFlags: DISPFlags, TParam: &'a DIArray, ) -> &'a DISubprogram; </ins> pub fn LLVMRustDIBuilderCreateBasicType<'a>( Builder: &DIBuilder<'a>, Name: *const c_char,

Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim


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

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


Question: /// # Examples /// /// ``` <del> /// #![feature(osstring_ascii)] </del> /// use std::ffi::OsString; /// let s = OsString::from("Grüße, Jürgen ❤"); /// /// assert_eq!("GRüßE, JüRGEN ❤", s.to_ascii_uppercase()); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> pub fn to_ascii_uppercase(&self) -> OsString { OsString::from_inner(self.inner.to_ascii_uppercase()) }

<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] - Stabilized traits necessary to obtain [x] - Added ASCII methods on [x] Final commenting period (FCP) [x] - Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Just needed to manipulate paths on windows -- I need to lower case driver letter, -.
Currently, SQLx contains The UTF-8 check that is included in there, while not a problem in practice, seems pointless. Changing to lands me here because of the .


Question: /// # Examples /// /// ``` <del> /// #![feature(osstring_ascii)] </del> /// use std::ffi::OsString; /// let s = OsString::from("Grüße, Jürgen ❤"); /// /// assert_eq!("GRüßE, JüRGEN ❤", s.to_ascii_uppercase()); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> pub fn to_ascii_uppercase(&self) -> OsString { OsString::from_inner(self.inner.to_ascii_uppercase()) }

Also, if somebody did a similar thing with instead of , the version could drop that and would then be a bit less noisy.
is a stabilization PR. Since lib team wants to do fcp in the tracking issue. could you start one ?
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] [ ] Concerns: resolved by 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.
Slight question about -- normally when dealing with AsRef args, they come in without an explicit reference in the signature (), except when necessary to support a lifetime in the return value (). Currently is declared as: Is this supposed to be instead? concern eqignoreasciicase &S
I think it should be. I'm not sure why I wrote it like I did originally, but this makes more sense to me. I can make that PR if needed. Or can it be done in the stabilization PR? Not sure what the process is from here.
resolve eqignoreascii_case &S reviewed Fixed in .
: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.
you can tick the FCP box, as the FCP is complete.


Question: } hir::ImplItemKind::Type(_) => false, }, <ins> Node::Expr(&hir::Expr { kind: hir::ExprKind::Closure(..), .. }) => true, </ins> _ => false, } }

Regression in ( cc modify labels: +regression-from-stable-to-stable -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Beta backport accepted as per compiler team . A backport PR will be authored by the release team at the end of the current development cycle. label +beta-accepted


Question: <ins> // edition:2018 // compile-flags: -Cincremental=tmp/issue-72766 pub struct SadGirl; impl SadGirl { pub async fn call(&self) -> Result<(), ()> { Ok(()) } } async fn async_main() -> Result<(), ()> { // should be `.call().await?` SadGirl {}.call()?; //~ ERROR: the `?` operator can only be applied to values Ok(()) } fn main() { let _ = async_main(); } </ins>

<!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc


Question: <ins> error[E0603]: tuple struct constructor `A` is private --> $DIR/issue-111220-2-tuple-struct-fields-projection.rs:27:13 | LL |         let Self(a) = self; |             ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0603`. </ins>

I tried this code: I expected to see this happen: compilation should fail because the trait impl is defined outside of the module for the type but refers to its private field. Instead, this happened: this compiled successfully This reproduces on the playground for stable Rust, version 1.69.0:
Adding a main function and attempting to call the (playground link: ) raises the compilation error: !
This can be reproduced with cross-crate (e.i., any other crate can access the private field). This means that all encapsulations that take advantage of the field being private can be bypassed. (For example, if we change Vec to a tuple struct, the same thing as setlen could be done in safe code by abusing this bug.) label +I-unsound Also, this can be reproduced in all versions where is stable (e.i., 1.32+). It's a matter of how you initialize Foo. If you provide a constructor for Foo, you won't get a compile error:
Just for completeness, turning this into a segfault without external crates/just std:
label A-visibility
this has been unsound ever since in version 1.32
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: //@[rust2021] edition:2021 fn main() { println!('hello world'); <del> //[rust2015,rust2018,rust2021]~^ ERROR unterminated character literal </del> <ins> //~^ ERROR unterminated character literal //[rust2021]~| ERROR prefix `world` is unknown </ins> }

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


Question: <ins> #![feature(never_type)] #![deny(dead_code)] pub struct T1(!); pub struct T2(()); pub struct T3<X>(std::marker::PhantomData<X>); pub struct T4 { _x: !, } pub struct T5<X> { _x: !, _y: X, } pub struct T6 { _x: (), } pub struct T7<X> { _x: (), _y: X, } pub struct T8<X> { _x: std::marker::PhantomData<X>, } pub struct T9<X> { //~ ERROR struct `T9` is never constructed _x: std::marker::PhantomData<X>, _y: i32, } fn main() {} </ins>

The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types).


Question: <ins> #![feature(never_type)] #![deny(dead_code)] pub struct T1(!); pub struct T2(()); pub struct T3<X>(std::marker::PhantomData<X>); pub struct T4 { _x: !, } pub struct T5<X> { _x: !, _y: X, } pub struct T6 { _x: (), } pub struct T7<X> { _x: (), _y: X, } pub struct T8<X> { _x: std::marker::PhantomData<X>, } pub struct T9<X> { //~ ERROR struct `T9` is never constructed _x: std::marker::PhantomData<X>, _y: i32, } fn main() {} </ins>

So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.


Question: return krate; } <del> krate.module.items.push(mk_decls(&mut cx, &derives, &attr_macros, &bang_macros)); </del> <ins> krate.module.items.push(mk_decls(&mut cx, &macros)); </ins> krate }

The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)


Question: attrs: Vec<ast::Name>, } <ins> enum ProcMacroDefType { Attr, Bang } </ins> struct ProcMacroDef { function_name: Ident, span: Span, <ins> def_type: ProcMacroDefType } enum ProcMacro { Derive(ProcMacroDerive), Def(ProcMacroDef) </ins> } struct CollectProcMacros<'a> { <del> derives: Vec<ProcMacroDerive>, attr_macros: Vec<ProcMacroDef>, bang_macros: Vec<ProcMacroDef>, </del> <ins> macros: Vec<ProcMacro>, </ins> in_root: bool, handler: &'a errors::Handler, is_proc_macro_crate: bool,


Question: let ecfg = ExpansionConfig::default("proc_macro".to_string()); let mut cx = ExtCtxt::new(sess, ecfg, resolver); <del> let (derives, attr_macros, bang_macros) = { let mut collect = CollectProcMacros { derives: Vec::new(), attr_macros: Vec::new(), bang_macros: Vec::new(), in_root: true, handler, is_proc_macro_crate, is_test_crate, }; if has_proc_macro_decls || is_proc_macro_crate { visit::walk_crate(&mut collect, &krate); } (collect.derives, collect.attr_macros, collect.bang_macros) </del> <ins> let mut collect = CollectProcMacros { macros: Vec::new(), in_root: true, handler, is_proc_macro_crate, is_test_crate, </ins> }; <ins> if has_proc_macro_decls || is_proc_macro_crate { visit::walk_crate(&mut collect, &krate); } // NOTE: If you change the order of macros in this vec // for any reason, you must also update 'raw_proc_macro' // in src/librustc_metadata/decoder.rs let macros = collect.macros; </ins> if !is_proc_macro_crate { return krate }


Question: <ins> // edition:2021 // run-rustfix #![allow(dead_code)] async fn a() {} async fn foo() -> Result<(), i32> { a().await //~ ERROR mismatched types } fn main() {} </ins>

This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/


Question: use prelude::v1::*; use io::prelude::*; use io::{self, BufReader, BufWriter, LineWriter, SeekFrom}; <ins> use sync::atomic::{AtomicUsize, Ordering}; use thread; </ins> use test; /// A dummy reader intended at testing short-reads propagation.

There is a panic safety issue in : after a call panics, the impl of calls again, which means the buffer contents are potentially written twice. This may cause an application to overwrite parts of a file that it did not mean to overwrite (in a DB engine written in Rust, this could cause unrecoverable data corruption!). Demonstration: The expected output of the demo program is , the actual output is: More generally, we need a story for panic safety in Rust. My takeaway from the related discussions (e.g. , , the trait) was that only code and impls should have to worry about panic safety. The demo app contains none of these, so I'd consider this a bug in . (otherwise all implementations would need to provide the strong exception safety guarantee?) Solution: could use temporarily mark the buffer as empty during the calls; so that the impl doesn't do anything after a panic. However, this doesn't help if the panic occurs during a call...
Note that Rust is normally referring to "memory safety" when talking about safety, so the issue here isn't in conflict with the related discussions. It's definitely a bug in , but I want to point out how specific it is here: the only reason you have odd behaviour is because you have a implementation that will panic after successfully writing the data it is given. I'm all for making more robust, but it's not just "if the call panics", it's "if the call panics after successfully writing data". Panicking before a successful write (or if the write fails), would not have the same issue.
If your impl is panicking in the middle of a write, it seems to me like you're in data corruption land with or without a second write. This is not quite the case - and thread locals expand that surface area. What's specifically the expected behavior here? Is the implementation specifically the thing that needs tweaking, or should the totally poison itself? For reference, Java's class has no special handling for exceptions thrown from the inner : , so adjusting alone seems like a reasonable route to take.
Without the , a panic in the middle of a write (without ) only corrupts the part of the file that the application meant to overwrite. In a DB engine context, that means the resulting corruption can be repaired when the transaction is rolled back.


Question: use prelude::v1::*; use io::prelude::*; use io::{self, BufReader, BufWriter, LineWriter, SeekFrom}; <ins> use sync::atomic::{AtomicUsize, Ordering}; use thread; </ins> use test; /// A dummy reader intended at testing short-reads propagation.

But with , a panic after some data was written might corrupt parts of the file that are not saved in the rollback journal, so recovery not possible. I think we need some guideline like: If a method call panics, it's a bug to call any additional methods on the same object. Thus, the bug is in . may need something similar to a poison-flag so that the impl can detect whether a previous call panicked, but it doesn't need to protect against it's own methods being called after a panic (that would be considered a bug in the caller). The Java has the same problem, but the expectation in the Java world is different: it's trivially possible to catch an exception and continue using the potentially-invalid state; so in Java's case I would argue that all implementations should provide the strong exception safety guarantee to avoid this kind of issue. Essentially, the Rust world needs to decide between a Java/C++-style "strong exception safety guarantee" (=failing method call should not have any side effects) or a new "no-use-after-panic guarantee" (=after a failing method call, no additional method calls should occur). Some types (like BufWriter) can be compatible with at most one of the guarantees -- strong exception safety requires that a panicking call has no side effects; no-use-after-panic requires that a panicking call has the side effect of suppressing the buffer flush in the impl. The trait seems to be roughly equivalent to basic exception safety. Types that do not implement instead live in the world. Generic types implementing need to be careful not to call any functions on the type parameter from within the implementation if a previous call panicked (unless they use a bound).
triage: P-medium is fixing the data corruption in


Question: // this function uses `unwrap` copiously, because an already validated constant must have valid // fields and can thus never fail outside of compiler bugs <del> pub fn const_variant_index<'tcx>( </del> <ins> pub(crate) fn const_variant_index<'tcx>( </ins> tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, val: &'tcx ty::Const<'tcx>,

Follow-up to agreed to move to . Generally I propose that should not contain code that is only needed by CTFE. We have and in there are they need some very deep access to Miri engine internals, but at least those are separate modules. Also, has grown pretty messy, and it does not seem like the order of definitions in that file follows any principle. We could split the file into two similar to what I did with Miri: for implementing the machine trait and defining everything that is needed during CTFE execution, and for defining the setup functions and all the glue that connects CTFE with the rest of the compiler.