Question: } None => { debug!(?param.ident, ?param.ident.span); let deletion_span = deletion_span(); <del> self.r.lint_buffer.buffer_lint_with_diagnostic( lint::builtin::UNUSED_LIFETIMES, param.id, param.ident.span, &format!("lifetime parameter `{}` never used", param.ident), lint::BuiltinLintDiagnostics::SingleUseLifetime { param_span: param.ident.span, use_span: None, deletion_span, }, ); </del> <ins> // the give lifetime originates from expanded code so we won't be able to remove it #104432 let lifetime_only_in_expanded_code = deletion_span.map(|sp| sp.in_derive_expansion()).unwrap_or(true); if !lifetime_only_in_expanded_code { self.r.lint_buffer.buffer_lint_with_diagnostic( lint::builtin::UNUSED_LIFETIMES, param.id, param.ident.span, &format!("lifetime parameter `{}` never used", param.ident), lint::BuiltinLintDiagnostics::SingleUseLifetime { param_span: param.ident.span, use_span: None, deletion_span, }, ); } </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. --code from requires debug assertions <!-- 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 --<!-- TRIAGEBOTEND --
lol, nightly emits this:D : another one from
any updates? :upsidedownface:
claim I think I got a fix :slightlysmilingface:
Error: Parsing assign command in failed: ...' claim' ' I think I'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim


Question: multibyte_chars, non_narrow_chars, name_hash, <del> } </del> <ins> }) </ins> } /// Returns the `BytePos` of the beginning of the current line.

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


Question: fn ilog10_u128() { ilog10_loop! { u128, 38 } } <ins> #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog2_of_0_panic() { let _ = 0u32.ilog2(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog10_of_0_panic() { let _ = 0u32.ilog10(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog3_of_0_panic() { let _ = 0u32.ilog(3); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog0_of_1_panic() { let _ = 1u32.ilog(0); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog1_of_1_panic() { let _ = 1u32.ilog(1); } </ins>

Filing since it's in pFCP over at , and I don't think we can reasonably change it after stabilization (especially since it's documented). Currently, in release mode evaluates to . (And same for the other bases.) It's not obvious to me that that's necessarily the best option. For example, the implementation is slightly nicer on CPUs from the past or so (and I think would be just as nice on older ones ), but gives <subas u32</subin the wrapping case. It also might be nice to have the wrapping case give something clearly different from any of the successful cases, rather than having and give the same thing. For example returns in release mode, which isn't a power of two (according to ), so it's distinguishable from all the non-wrapping cases. This only affects // on . (The checked versions don't have an issue, nor do the ones on .)
I couldn't find any previous discussion of what the exact wrapping value ought to be, just that there ought to be one, as opposed to a . There was this note: For which I think the implementation I mention above is a counter-example, albeit only for the base-2 case. Also, currently in release mode is essentially , so we can pick any value we want to return for those cases. FWIW, the implementation in gives as the result for .
In Rust we try to do the right thing. Not even Python gives -1. Let's avoid in-band error values in Rust.
What's your proposal for what the "right" thing is, then? That panic in release too? Arguably the most-correct value is −∞ (like ), but that doesn't fit in any of our integer types. So would make sense, but release mode for the other un-prefixed things is wrapping, not saturating.
Python has some functions that return in-band values: "xy".find("y") 1 "xy".find("z") -1 From Rust I expect something better. In Rust if a function isn't naturally total and you can't restrict its input, then I expect it to return Option (or Result), or when that's isn't ergonomic enough, a panic (in release too). Returning -1 is dangerous as that Python find function, returning 0 is not math.


Question: fn ilog10_u128() { ilog10_loop! { u128, 38 } } <ins> #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog2_of_0_panic() { let _ = 0u32.ilog2(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog10_of_0_panic() { let _ = 0u32.ilog10(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog3_of_0_panic() { let _ = 0u32.ilog(3); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog0_of_1_panic() { let _ = 1u32.ilog(0); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog1_of_1_panic() { let _ = 1u32.ilog(1); } </ins>

I think returning (wrapped if necessary) is a clear distinguish between normal and error result. Returning an is not ideal currently because it will makes the function practically unusable in const context (before const unwrap is stabilized) If getting closest to the "correct" math answer, how about choosing ? However it seems weird and still seems better to me
Perhaps in other languages. Rust is known for being better than that. I have chosen to use Rust because it's a bit better than Python (see above). Let's return Option and and wait for const unwrap to be stabilized before making ilog const, then.
That's what does already. Is your proposal, then, that the version of just shouldn't exist on ? How do you square that with precedent of other things -- like or -- that have the version return , but the un-prefixed one wrap in release mode?
what about treating it like division by zero and just panicking?
I'd be fine with -1. The point of these methods is to get fast code (otherwise many won't use them and will prefer to do to keep the code branchless and avoid the ugly ) and a defined value outside of the usual input range. (from above) is a good example. If you want stricter guarantees than that, you can use .
A minor point: being 0 is actually a reasonable choice - even though 0 is not a power of two, it is congruent to the correct power of two modulo 2^32 (which is 2^32 itself), so exactly what is expected in wrapping arithmetic. But unfortunately there's no "−∞ mod 2^32" that could be used for .
Modular arithmetic is confusing in the context of logarithm, if you want to return the discrete logarithm of 0 in the release mode, then there are a lot of candidates, because (in case of ) therefore in the sense of modular arithmetic, could be any multiple of . If you really want to achieve something close to , then I guess the best value is as I mentioned above. (Interestingly though, = , which is a multiple of 8, 16, 32, 64, 128)
That's certainly a possibility. suggested not doing that back in the original PR, though:
Doesn't implicitly include a check for zero in the code generated?


Question: fn ilog10_u128() { ilog10_loop! { u128, 38 } } <ins> #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog2_of_0_panic() { let _ = 0u32.ilog2(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog10_of_0_panic() { let _ = 0u32.ilog10(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog3_of_0_panic() { let _ = 0u32.ilog(3); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog0_of_1_panic() { let _ = 1u32.ilog(0); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog1_of_1_panic() { let _ = 1u32.ilog(1); } </ins>

]
Also, since the methods are implemented for signed integers as well, another issue would be the log of negative values. For example for floating-point, would return −∞, but would return NaN. So if would return some value for −∞, would panic anyway, or return some value?
I don't think it makes sense to do anything other than panic in the case of negative values, which in turn is probably an argument for panicking on zero as well. I guess one could argue that "wrapping" could be interpreted as wrapping the preimage to fit in the function's domain (rather than just wrapping the image to fit in the range) but IMO that would be entirely unintuitive and unhelpful as well. After thinking about it a bit, it seems to me that simply cannot have a meaningful variant, because semantics (as reasonably interpreted) cannot answer the question "what should the result be for values for which the original function is undefined?" There are no elements in 's domain for which the function underflows or overflows.
That's only the case on old chips. As I linked in the OP (), that happens in the instruction generation very-last-phase of LLVM on old chips, and on newer chips it knows to emit a different instruction instead of the branching code: The good news is that it looks like newer LLVM has gotten smarter here. It used to be that, because of how the intrinsic gets translated, it would emit obviously-redundant assembly on old chips in some code patterns, as you could see in Rust 1.16:
is supposed to find the largest so that . Since computers use wrapping arithmetic, the equation is better put as . The largest satisfying this equation in the case is (aka ). So if we consider a wrapping to be the inverse of , makes perfect sense (and is very efficient on modern CPUs, as others have pointed out). I would also advocate for to be as a method which always has this behaviour. [Edit: it already behaves that way]
Note that's already how works . It's just that it wraps to in release right now -- this issue doesn't propose removing the panic in debug behaviour, just to figure out what the best value for release would be.


Question: fn ilog10_u128() { ilog10_loop! { u128, 38 } } <ins> #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog2_of_0_panic() { let _ = 0u32.ilog2(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog10_of_0_panic() { let _ = 0u32.ilog10(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog3_of_0_panic() { let _ = 0u32.ilog(3); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog0_of_1_panic() { let _ = 1u32.ilog(0); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog1_of_1_panic() { let _ = 1u32.ilog(1); } </ins>

Since, from the notes, it seems like the libs-api meeting today said "how about we panic instead of wrap", I'll try to answer my own question from above: I would propose the following rule: Conceptually, the result is first calculated in true ℤ (aka to infinite precision). Then for the non-prefixed versions If that result is undefined (, , etc), then it panics (regardless of compilation mode) If that result is defined and fits in the result type, it's returned. If that result is defined but not in-range for the result type, it panics if overflow checking is enabled, and wraps (mod 2<supN</supfor uN) if overflow checking is disabled. I think that's consistent with all the current precedent. ( also is good reading about the distinction I'm drawing here.)
I would redefine that to include cases where the result is defined but you can't wrap that to the result type, e.g. or . that would cover and
I agree, but was considering that implied by "in ℤ", as that set includes neither −∞ nor ⅈ. (Like how is , not a complex number.)
I'm not necessarily against panicking in that case. I just pointed out how it's a bit inconsistent with the other operations we have on integers. (Whether it makes sense for the other operations to have this difference in behavior between debug and release mode is an interesting discussion too, but I'm afraid that ship has sailed.) The reason we don't always panic on overflow for and etc. is performance. It's simply too costly to do. (We always panic on division by zero because that's both mathematically undefined (even modulo 2<supBITS</sup) and because on some platforms, the native division instruction will signal/abort/trap the program when the right hand side is zero.) We applied the same reasoning to things like and , although one might reasonably argue that for those it might be fine to always panic, since these are not as common as and . (You could then still use if you really want to make sure there's no check, if you're sure it's unnecessary.) That seems reasonable. It'd be nice if it'd still be easy to get the efficient calculation through some usage of or though.


Question: fn ilog10_u128() { ilog10_loop! { u128, 38 } } <ins> #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog2_of_0_panic() { let _ = 0u32.ilog2(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog10_of_0_panic() { let _ = 0u32.ilog10(); } #[test] #[should_panic(expected = "argument of integer logarithm must be positive")] fn ilog3_of_0_panic() { let _ = 0u32.ilog(3); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog0_of_1_panic() { let _ = 1u32.ilog(0); } #[test] #[should_panic(expected = "base of integer logarithm must be at least 2")] fn ilog1_of_1_panic() { let _ = 1u32.ilog(1); } </ins>

It looks like llvm isn't smart enough today to turn into simply a count-leading-zeros and a subtract instruction. :(
We discussed this again in the libs-api meeting, and we concluded pretty much the same as rule, meaning that these functions should panic on zero in all compilation modes, since there's not a modulo-2<supN</sup-correct result.


Question: | LL |         MyEnum::Struct => "", |         ^^^^^^^^^^^^^^ not a unit struct, unit variant or constant <ins> | help: the struct variant's field is being ignored | LL |         MyEnum::Struct { s: _ } => "", |                        ++++++++ </ins> error: aborting due to 2 previous errors

I wrote code that looked like this while not having my brain turned on 100%. Due to said brain not functioning, it took me a while to understand what rustc was trying to tell me with the message pointing to the pattern with the text . sure looked like a unit variant to me! What rustc was trying to tell me was that the definition of the variant was a struct variant ("found struct variant") and my pattern wasn't matching the definition ("this pattern you specified looks like it's trying to match a variant that is not a unit struct, unit variant or constant"). The change I needed to make was adding to my pattern, because I was trying to distinguish different variants from each other, not use pieces within the variants. Suggesting seems like a decent starting point to me, but there could definitely be cases I'm not considering here and I'm totally open to hearing that No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WEIRD this PR looks like it implements what I wish rustc did: but the test files in that PR say they're for and I'm getting
Aha ok this test shows that for tuple variants, rustc will suggest adding : and that test also shows that rustc isn't suggesting anything for struct variants!
Aha and it looks like adding struct fields was more complex so that's why it wasn't done?
claim


Question: <ins> error[E0308]: mismatched types --> $DIR/mut-mut-wont-coerce.rs:36:14 | LL |     make_foo(&mut &mut *result); |     -------- ^^^^^^^^^^^^^^^^^ expected `*mut *mut Foo`, found `&mut &mut Foo` |     | |     arguments to this function are incorrect | = note:    expected raw pointer `*mut *mut Foo` found mutable reference `&mut &mut Foo` note: function defined here --> $DIR/mut-mut-wont-coerce.rs:30:4 | LL | fn make_foo(_: *mut *mut Foo) { |    ^^^^^^^^ ---------------- error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>

The title already says it, but as an illustrating example you can have a look at Since &mut T can be implicitly converted to *mut T, I wondered whether there's a reason that it doesn't work for &mut &mut T (besides "no one has implemented it" :smile: ). pointed out that this might be (in IRC). The example code also illustrates a somewhat unexpected failure of type inference, which might be worth filing as a separate issue.
Hmm... take the following: Rust will currently complain about mismatched types for the second coercion. It's not clear such a coercion should exist: it's like converting a to a .
Note that first coercing to instead of seems to work ().
Your testcase is constructing a , not a .
Ah, thanks for pointing that out.
In don't know if I understand your point, but if you argue that such a coercion should not exist because it might be unsafe, the line in my original example shows that this conversion is already possible in safe code.
Heh, C++ has special rules for multi-level pointer conversions exactly to prevent these kinds of type unsafeties: "More qualified" relations can be translated to Rust's // relations.
isn't doing the same thing: the outer is actually constructing a temporary, so you end up with an (as opposed to a ). Also, safety isn't really relevant; we allow arbitrary explicit pointer casts anyway.
Oh, wait, I see, you expect the original to interpreted as , and then converted from there to . That makes sense.
I think this would work if borrow expressions would take into account that they might get coerced later and pass down the from (where here), instead of only working for .
Triage: this still reproduces.
Closing this as the bug is fixed and playground link above works for all editions.
The playground link had the problematic line commented out: It still gives a compile error:
oops my bad then
This idea has been suggested. A T-compiler member has pointed out that other languages apply rules to restrain pointer coercion, specifically because multi-level pointer coercion is prone to being a bit of a footgun. Not quite "this is a bad idea", but despite the simplicity of the proposal, it deserves being treated with caution. There is no strong argument that this is a bug because it is consistent, if annoying.


Question: <ins> error[E0308]: mismatched types --> $DIR/mut-mut-wont-coerce.rs:36:14 | LL |     make_foo(&mut &mut *result); |     -------- ^^^^^^^^^^^^^^^^^ expected `*mut *mut Foo`, found `&mut &mut Foo` |     | |     arguments to this function are incorrect | = note:    expected raw pointer `*mut *mut Foo` found mutable reference `&mut &mut Foo` note: function defined here --> $DIR/mut-mut-wont-coerce.rs:30:4 | LL | fn make_foo(_: *mut *mut Foo) { |    ^^^^^^^^ ---------------- error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>

Legalizing this behavior with narrow cases seems permissible, but amounts to a new language feature design request. Transitive coercions, as part of the revised coercion rules, are . Accordingly, I think this should also be closed... but not before documenting the current behavior in the form of a regression test.


Question: <ins> warning: unused variable: `props_2` --> $DIR/issue-87987.rs:11:9 | LL |     let props_2 = Props { |         ^^^^^^^ help: if this is intentional, prefix it with an underscore: `_props_2` | = note: `#[warn(unused_variables)]` on by default warning: field is never read: `field_1` --> $DIR/issue-87987.rs:5:5 | LL |     field_1: u32, |     ^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default warning: field is never read: `field_2` --> $DIR/issue-87987.rs:6:5 | LL |     field_2: u32, |     ^^^^^^^^^^^^ warning: 3 warnings emitted </ins>

Encountered an ICE when building  0.18.0 on edition 2021. I have roughly narrowed it down to the following (can probably be reduced further). Seems to be an issue with closure captures. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The code can be further simplified to: The issue seems to be around using type annotation. If a type annotation is included, the right hand side of the let statement should always be read.
Is there a runtime check/ is MIR generated for checking if is valid? Because if that's the case then we need props2 to be caputred.
claim I should have a fix later tonight
We found another instance of this ICE that still fails with included: Found trying to migrate . Let me know if you need any more information.


Question: // of llvm-config, not the target that we're attempting to link. let mut cmd = Command::new(&llvm_config); cmd.arg("--libs"); <ins> // Force static linking with "--link-static" if available. let mut version_cmd = Command::new(&llvm_config); version_cmd.arg("--version"); let version_output = output(&mut version_cmd); let mut parts = version_output.split('.'); if let (Some(major), Some(minor)) = (parts.next().and_then(|s| s.parse::<u32>().ok()), parts.next().and_then(|s| s.parse::<u32>().ok())) { if major > 3 || (major == 3 && minor >= 8) { cmd.arg("--link-static"); } } </ins> if !is_crossed { cmd.arg("--system-libs"); }

In 1.12, figures out which libraries it needs for external LLVM using which breaks if you have LLVM with and (which is needed for clang 3.9 these days), since then there is a dynamic and lots of , but the code sees the and decides it has to link statically, which fails. The code should decide whether to link static or dynamic first, and then call resp , to get the correct library name.
Thanks for the report! Sounds like it should be a relatively easy bug to tackle as well!
In Void, we work around it by just adding , I guess for a general fix you need some policy how to link it.
Oh we basically always want to link LLVM statically, so we can probably just always pass it.
We emphatically don't want that in distro builds. Would you accept a patch to make this conditional?
certainly!


Question: <del> error: field `1` is never read --> $DIR/tuple-struct-field.rs:8:26 </del> <ins> error: fields `1`, `2`, `3`, and `4` are never read --> $DIR/tuple-struct-field.rs:8:28 </ins> | <del> LL | struct SingleUnused(i32, [u8; LEN], String); |        ------------      ^^^^^^^^^ </del> <ins> LL | struct UnusedAtTheEnd(i32, f32, [u8; LEN], String, u8); |        --------------      ^^^  ^^^^^^^^^  ^^^^^^  ^^ </ins> |        | <del> |        field in this struct </del> <ins> |        fields in this struct </ins> | <ins> = help: consider removing these fields </ins> note: the lint level is defined here --> $DIR/tuple-struct-field.rs:1:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ <del> help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field </del> <ins> error: field `0` is never read --> $DIR/tuple-struct-field.rs:13:27 | LL | struct UnusedJustOneField(i32); |        ------------------ ^^^ |        | |        field in this struct </ins> | <del> LL | struct SingleUnused(i32, (), String); |                          ~~ </del> <ins> = help: consider removing this field </ins> <del> error: fields `0`, `1`, `2`, and `3` are never read --> $DIR/tuple-struct-field.rs:13:23 </del> <ins> error: fields `1`, `2`, and `4` are never read --> $DIR/tuple-struct-field.rs:18:31 </ins> | <del> LL | struct MultipleUnused(i32, f32, String, u8); |        -------------- ^^^  ^^^  ^^^^^^  ^^ </del> <ins> LL | struct UnusedInTheMiddle(i32, f32, String, u8, u32); |        -----------------      ^^^  ^^^^^^      ^^^ </ins> |        | |        fields in this struct | help: consider changing the fields to be of unit type to suppress this warning while preserving the field numbering, or remove the fields | <del> LL | struct MultipleUnused((), (), (), ()); |                       ~~  ~~  ~~  ~~ </del> <ins> LL | struct UnusedInTheMiddle(i32, (), (), u8, ()); |                               ~~  ~~      ~~ </ins> <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 3 previous errors </ins>

The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: } } <del> return ty::ExistentialBounds { region_bound: region_bound, builtin_bounds: builtin_bounds, projection_bounds: projection_bounds }; </del> <ins> ty::ExistentialBounds::new( region_bound, builtin_bounds, projection_bounds) </ins> } fn parse_builtin_bounds(&mut self) -> ty::BuiltinBounds {

It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).


Question: } } <del> return ty::ExistentialBounds { region_bound: region_bound, builtin_bounds: builtin_bounds, projection_bounds: projection_bounds }; </del> <ins> ty::ExistentialBounds::new( region_bound, builtin_bounds, projection_bounds) </ins> } fn parse_builtin_bounds(&mut self) -> ty::BuiltinBounds {

Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/


Question: use crate::io::{self, IoSlice, IoSliceMut}; use crate::mem; <del> use crate::sync::atomic::{AtomicBool, Ordering}; </del> use crate::sys::fd::FileDesc; use crate::sys::{cvt, cvt_r}; <del> use libc::c_int; </del> //////////////////////////////////////////////////////////////////////////////// // Anonymous pipes ////////////////////////////////////////////////////////////////////////////////

Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: uses the flag with  (mentioned above, in 2.6.23) uses with  ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") uses  to atomically set the flag on the pipe fds ( in 2.6.27) uses with  ( in 2.6.27) uses  to permit use of ( in 2.6.28) ~ ( in 4.5, not fixed by this proposal)~ As you can see, the workarounds fixed by this proposal all have a similar flavor. Originally posted by in
Kernel updated in .
As noted, needs a much newer kernel 4.5, so we'll still need that fallback. But all the stuff should be ok to assume available now.
The new minimal version is 2.6.27 from what I can see, so "Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC" still needs a fallback, right?
The builder is using 2.6.32 headers, so I would call that our new minimum.
Ah right; I am actually not sure where I got the 27 from...
The title of suggested 2.6.27, but we went a little higher to match the actual distros in use.
I know this is ancient history, but do you recall the problem with ? You introduced that comment about "some kernel" in , and you were the last to update it in . If the problem kernels were before 2.6.32, then I'd like to clean that up now.
Just digging in kernel history, I did find one hiccup in , but that bug was introduced and resolved during the 3.7 development cycle, not in a release.
IIRC we just mirrored what musl did at the time, which looks like it : Looks like the original mailing list thread is gone and there's no comments in the musl source, and I don't recall what happened here. I suspect it would be safe to remove those workarounds and just assume works one the first try until someone says differently.


Question: /// Basic usage: /// /// ``` <del> /// #![feature(nonzero_leading_trailing_zeros)] </del> #[doc = concat!("let n = std::num::", stringify!($Ty), "::new(", stringify!($LeadingTestExpr), ").unwrap();")] /// /// assert_eq!(n.leading_zeros(), 0); /// ``` <del> #[unstable(feature = "nonzero_leading_trailing_zeros", issue = "79143")] #[rustc_const_unstable(feature = "nonzero_leading_trailing_zeros", issue = "79143")] </del> <ins> #[stable(feature = "nonzero_leading_trailing_zeros", since = "1.53.0")] #[rustc_const_stable(feature = "nonzero_leading_trailing_zeros", since = "1.53.0")] </ins> #[inline] pub const fn leading_zeros(self) -> u32 { // SAFETY: since `self` can not be zero it is safe to call ctlz_nonzero

Tracking issue for trailingzeros and leadingzeros for non zero types as introduced by . The feature gate for the issue is . On many architectures, this functions can perform better than trailingzeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
It seems on my (common) architecture it doesn't give an advantage: : : So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough?
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)
merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
started to make the stabilization PR but hit a problem I think that constcttz needs to be stabilized for this to be stabilized from //! If an intrinsic is supposed to be used from a with a attribute, //! the intrinsic's attribute must be , too. Such a change should not be done //! without T-lang consulation, because it bakes a feature into the language that cannot be //! replicated in user code without compiler support.


Question: } if let ExprKind::StaticRef { def_id, .. } = expr.kind { let is_thread_local = this.hir.tcx().has_attr(def_id, sym::thread_local); <ins> local_decl.internal = true; </ins> local_decl.local_info = LocalInfo::StaticRef { def_id, is_thread_local }; } this.local_decls.push(local_decl)

root: updns-0.0.6: v.
triage: P-high. Nominating for discussion.
self-assigned for investigation in short term (as in, next two or three days). However I suspect someone from will be a better choice to investigate this.
We should try to bisect this
used . Determined: searched nightlies: from nightly-2019-11-26 to nightly-2020-01-03 regressed nightly: nightly-2019-12-01 searched commits: from to  regressed commit:
is a rollup commit of the following PR's: I'm guessing this is due to PR
I'm still working on reducing this down to something that I could put into the playpen. However, one interesting thing I've found locally during my reduction: This version of the will signal an analogous compilation error: but if I lift the first argument out to a separate -binding (i.e. change it to use above, or the sub-expression out to a separate -binding (i.e. change the argument expression to use above), then the error goes away. I'll admit that I don't know all the details of how the fn-transformation works to support , but I strongly suspect that if this kind of local code change can make an error go away, then that represents a weakness somewhere (either in the fn-transformation, or in the borrowck).
Okay in the details block is a standalone version suitable for the : <details</detailsand the error it generates:
So this does seem like somewhat clear (expected?) fallout from PR : a use of a in a generator witness will be recorded as a unsafe pointer , and then is never , but the method requires that the task you give it is . I believe we can readily update the crate in question to avoid using the in the expression under the RHS of . But I do wonder whether we can/should improve the diagnostics here to try to guide the user towards such a solution ...?
I might have worded this too strongly, and/or over-reduced my example. In particular, its easy to move around the access to . But the borrow of may be trickier to deal with.
I'll have a look at addressing this with another approach I considered for . If that doesn't work out then I'll have a look at the error message.


Question: } if let ExprKind::StaticRef { def_id, .. } = expr.kind { let is_thread_local = this.hir.tcx().has_attr(def_id, sym::thread_local); <ins> local_decl.internal = true; </ins> local_decl.local_info = LocalInfo::StaticRef { def_id, is_thread_local }; } this.local_decls.push(local_decl)

The patch linked is enough to fix the crate in question, but I'm all for finding an in-compiler solution if we can do it soundly.
OK. I'm going to write some things up because I've changed my mind a bunch of times about how/if this can be fixed in MIR building and I don't want to keep forgetting things. Generators store values that if their value needs to be preserved across a yield. These values need to be visible for auto-traits, for example a generator may be resumed on a different thread after it yields, and so cannot be if any of theses values isn't . There are two passes that determine which values can be included in the generator: A pass that runs as part of typeck that walks the HIR to find the types of expressions and then checks for yields in the values scope (as determined by the RegionScopeTree). The types recorded here are stored in the GeneratorWitnesss type contained in the generator, which is then used for auto trait checking. This notably uses the types of expressions that HIR sees. The MIR transform that lowers the generator to a state machine. This determines the values that the generator actually stores. As a check for the compiler, we assert that any types that we capture here are included in the witness type (we don't know all auto traits, so can't check only for them). After statics no longer have a special representation in MIR. They are instead lowered to a dereference of a pointer to the given static: is lowered as if it were: Which becomes: The example above is somewhat deceptive in that the temporary that holds the pointer is used immediately after it's assigned. In this case it cannot end up in the generator since it's not live across any user code. However this isn't true in all cases, index and match expressions allow running user code while the pointer is live: In these cases MIR has to put the temporary pointer into the generator state and promptly ICEs. The obvious solution now is make type checking record the new pointer types in the generator witness in these cases. Unfortunately HIR is not a great tool for specifying "these cases". The methods that the region scope tree provides in HIR are either usually far too large (the "temporary scope") or occasionally too small (the "enclosing scope"). went for the sound but rather approximate approach, leaving us here.


Question: } if let ExprKind::StaticRef { def_id, .. } = expr.kind { let is_thread_local = this.hir.tcx().has_attr(def_id, sym::thread_local); <ins> local_decl.internal = true; </ins> local_decl.local_info = LocalInfo::StaticRef { def_id, is_thread_local }; } this.local_decls.push(local_decl)

One idea might be to try changing MIR building so that the temporary is never live across user code. For example, one might change the lowering as follows However working out how to do this for in a reasonable to implement way is harder. MIR actually already contains an escape hatch for values that are in the MIR but aren't in the HIR in the form of a flag (called ) on the variable. We currently use it for drop flags and boxes created by expressions. It's unclear what exactly the difference is between is. I guess one could argue that auto traits are for layout introspection and this would be further breaking that. I think that's everything for now.
Visiting from triage. were you planning to work on this further?
It's definitely tempting to take advantage of the constraints around statics to just declare these equivalent, and use the flag to get out of this. While I don't see any soundness issues around that, I also don't quite trust myself to get this right :) Can you expand on this? I'm not sure I follow.
Another solution that comes to mind relies on the fact that these pointers never need to be stored in a generator. They are consts, and the temporaries containing them shouldn't ever be mutated. We could add semantics for "const temporaries" to MIR, and never store them inside generators. The semantics would (hopefully) be simple: defined once and assigned a value that doesn't depend on any other temporaries; never mutated or borrowed mutably. We can move the statements defining them to the top of the function inside the generator transform. But that would be adding more semantics and special casing to MIR to fix a change which removed extra semantics and special casing, so I'm not sure if that's what we want :)
The argument is that the given the following auto trait we guarantee that if then there are no raw pointers directly stored in an instance of . If we make that guarantee then using internal in generators would not be OK. I would argue that we're not making such (or really any) guarantees with user defined auto traits.
Yeah, I don't think auto traits should expose layout implementation details of generators. And this really does seem like a pure implementation detail -- it doesn't have any bearing on what kinds of (unsafe) operations are allowed on a generator, like a self-reference would.


Question: } if let ExprKind::StaticRef { def_id, .. } = expr.kind { let is_thread_local = this.hir.tcx().has_attr(def_id, sym::thread_local); <ins> local_decl.internal = true; </ins> local_decl.local_info = LocalInfo::StaticRef { def_id, is_thread_local }; } this.local_decls.push(local_decl)

cc
So, I've been putting off commenting here to let these ideas sit, but let me leave a comment. I think I've reached a conclusion. TL;DR. I think we should mark these types as internal, but I think there are some better options for fixing this in the medium term, and this interaction should be taken into account as part of the "MIR 2.0" effort to rework places. Auto traits weren't really intended as a tool for probing layout, but rather semantic considerations. This is why traits like can be implemented by users. So I don't really think that auto traits give any sort of guarantee about their layout. Rather, this question is about is simply "what are the constituent types exposed by a generator", and this should correspond to the types that user code can directly access. The raw pointers here are not directly accessible. The values that are accessible are the "live values" that the user's code may later use -- and of course the code currently makes the constituent types be a superset of those, based on the AST structure. Of course, the real root cause of this error is a simplifying change to the definition of in MIR. It used to be that a Place had this grammar: but now we changed to just , which is why we are required to introduce the new temporary (and that holds the address of the ). As we've been talking about this change, I've been saying that we should be considering the older definition of as the one that is used by various analyses (and in particular by borrow check). This particular transformation of removing statics doesn't affect borrow check, but we failed to take into account the fact that the set of live variables can effect the definition of what is live in a generator. In particular, compiling for some expression requires a temporary unless corresponds to a place -- those places used to include statics like , but they no longer do. But I think that for analysis purposes, it should appear as if they do. We could fix this in two ways. We could write some code motion / duplication that takes temporaries like that are live across a yield and creates a fresh variable after the yield. The idea would be to make them never* live across a yield.


Question: } if let ExprKind::StaticRef { def_id, .. } = expr.kind { let is_thread_local = this.hir.tcx().has_attr(def_id, sym::thread_local); <ins> local_decl.internal = true; </ins> local_decl.local_info = LocalInfo::StaticRef { def_id, is_thread_local }; } this.local_decls.push(local_decl)

We can do this because that operation is a compile-time constant, really, and thus the value doesn't need to be live across a yield. This might be worth doing as a size optimization regardless. Secondly, some of the proposals we've been kicking around for going further with simplifying include the idea of a distinct sort of temporaries that explicitly represent a "partially constructed that hasn't been used by the user". The idea was to allow borrowck (and other analyses) to trivially reconstruct the . We might want to add this interaction with auto-traits into the consideration for that design, and maybe it takes us some place (e.g., these special temporaries are not considered live for the purposes of auto traits). Having written out both of those options, though, I sort of lean towards the first, at least for this specific issue.
I think these references and raw pointers created by MIR construction should be marked as . They are not visible at the language level. They can be viewed as just prefetching the address of a static, so the compiler could pick any type it likes for it (, , , some compiler internal type) so it must not affect auto trait inference. Drop flags are ignored for similar reasons. You cannot use an auto trait like this to detect them: So I think that should be reverted and the temporary static references should be marked as .
Note: opened instituting this change and I r+'d it, since fixing the regression seems pretty important and time is of the essence; there is general consensus here on the thread; this is only restoring older behavior. In particular, there were some suggestions that this might be a lang team issue; I think there is some 'intersection' and I don't want the perception that I'm trying to shortcircuit discussion. That said, I also think this is primarily a compiler team matter, since it's a deviation from the old behavior, and further this deviation was caused by altering the MIR away from the "natural, Rust-based" definition and towards a lower-level definition.


Question: // `dyn T:` is lowered to `dyn T: ReEmpty` - check that we don't ICE in NLL for // the unexpected region. <del> // build-pass (FIXME(62277): could be check-pass?) </del> <ins> // check-pass </ins> trait T {} fn f() where dyn T: {} <del> fn main() {} </del> <ins> fn main() { f(); } </ins>

The following code () panics the compiler in stable 1.38.0, beta 1.39.0-beta.6, and nightly 2019-10-17: Removing the bound or filling it with makes it compile just fine. Error + backtrace:
cc
Hmm, I didn't know that adding a "syntactically trivial bound" could cause something like this. Is there some implicit bound that gets in cases like this?
minimized test case ():
The minimized test worked in previous stable Rust versions (at least in 1.33 under 2015 edition; though 2018 edition breaks there, which indicates this is with 99.999% certainty injected by MIR-borrowck...)
triage: P-high. Adding self to assignee list; removing I-nominated.


Question: const ENTRY_LIMIT: usize = 900; // FIXME: The following limits should be reduced eventually. <del> const ISSUES_ENTRY_LIMIT: usize = 1854; </del> <ins> const ISSUES_ENTRY_LIMIT: usize = 1852; </ins> const ROOT_ENTRY_LIMIT: usize = 867; const EXPECTED_TEST_FILE_EXTENSIONS: &[&str] = &[

we currently output The suggestion is incomplete and will not result in compilable code. Because the lifetime is coming from an argument of type , which is an unconstrained type parameter, itself will not have the needed lifetime and causes the obligation that we're trying to reverse by suggesting . The appropriate changes to the code would be either or , depending on whether appears in any other argument or not.
The suggested code .


Question: <ins> -include ../tools.mk all: $(HOST_RPATH_ENV) $(RUSTDOC) -w html -o $(TMPDIR)/doc foo.rs $(HTMLDOCCK) $(TMPDIR)/doc foo.rs $(HTMLDOCCK) $(TMPDIR)/doc qux/mod.rs </ins>

When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<


Question: <ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct Tuple; pub trait Trait<const I: usize> { type Input: From<<Self as Trait<I>>::Input>; } fn main() {} </ins>

results in an ICE (): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: use astconv::AstConv; use check::{self, FnCtxt}; <del> use middle::ty::{self, Ty}; </del> <ins> use middle::ty::{self, Ty, ToPolyTraitRef, AsPredicate}; </ins> use middle::def; <ins> use middle::lang_items::FnOnceTraitLangItem; use middle::subst::Substs; use middle::traits::{Obligation, SelectionContext}; </ins> use metadata::{csearch, cstore, decoder}; use syntax::{ast, ast_util};

I forget if there's already a bug on this, but it would be nice if, when you wrote and doesn't have a field named , but does have a nullary method named , the compiler gave a hint like "did you mean to write ?" It could also do vice versa (if you write A.B()ABA.B?) I ran into this in trans, where I have frequently written instead of .
Test: The error message is better now than it was: in that it suggests there is a method named . But it could still be improved. (The intention may not have been to take the method's value; it seems more likely that the programmer thought it wasn't a method at all.)
My previous comment still holds. It would be great if you would see the "try writing an anonymous function" hint for something like and instead see a "did you mean to write ?" in situations like this one.
I'd also like to see one when trying to call a function-typed struct field: emits Foof. It'd be nice if it tried to see if it could auto-deref to a struct field, and if so, say (f.f)().
A nice idea. Assigning P-low.
Currently gives which is pretty close to the proposed behavior. Replacing the wih yields the same as before (i.e. does not suggest removing the ):
Updated the example gives: which now prints It's nice that the note is there, but the text is suboptimal: isn't a function.
I'm working on a fix for this, but I'm struggling with the final portion. With this code: I get the output: My current changes are . I'm not sure if it's possible to have the output say "" and "kitty.x" with the input to the function. Any ideas? Or should I just keep the message in the same format as it is now and output "s.func" and "did you mean to write ?"? Edit: Ideally, I would like to output: I'm wondering if that's at all possible, especially because instead of , there might be an expression.
I got around that error message. Now I'm making sure the previous message is displayed under the proper circumstances.


Question: ) .lines() .map(|s| s.trim().to_owned()) <ins> .filter(|f| Path::new(f).extension().map_or(false, |ext| ext == "rs")) </ins> .collect(), ) }

When there was a change in a or other non-rust file, bootstrap tries to format it, which makes rustfmt very sad. cc and who broke this in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we just need to filter .rs files before passing them to rustfmt.
This will probably be hit a lot by contributors so I'll pin it for better visibility.
claim
Normally, the walker already filters for files, per Maybe the crate docs are not fully up to date, or I didn't understand them correctly.
The workaround is to run (notice the dot at the end of the command).
I think if we add it like this: will always not ignore it anymore.
Maybe try to put the part I before the ignore part, maybe this makes the ignore list work again? The thing that intrigues me the most is the fact that the files are not ignored later by the file type filter.
For any Rust files we changed locally, our current solution will try to format it, in some scenarios we may not want to format it, such as some files in UI?
Seems right, my current fix is not completed.
I think since you explicitly add the files to , that overrides the types filter.
from my local experiment, seems is still expected, I changed some files which ignored in , they are actually not sent to formatter:
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: <ins> // check-pass // edition:2021 // compile-flags: -Zunstable-options fn main() { let _: u16 = 123i32.try_into().unwrap(); } </ins>

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


Question: // originating from macros, since the segment's span might be from a macro arg. segment.ident.span.find_ancestor_inside(path_span).unwrap_or(path_span) }; <del> if error { </del> <ins> if let LifetimeRes::Error = res { </ins> let sess = self.r.session; let mut err = rustc_errors::struct_span_err!( sess,

I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.


Question: use std::alloc::{Global, Alloc, Layout, System}; <del> /// Issue #45955. </del> <ins> /// Issue #45955 and #62251. </ins> #[test] fn alloc_system_overaligned_request() { check_overalign_requests(System)

The man page for says And yet Miri found libstd calling this function with an alignment of 4 on a 64bit-platform. This happens when size=2, align=4. The fact that size<align makes it enter the code path for .
The only reason I can imagine for to exist there is a buggy implementation of . This check is only meaningful if a buggy implementation returns not an allocation suitably aligned for any built-in type (on x86_4 – 16-bytes) but rather an allocation aligned for the particular request?
A lack of comment is disturbing here. If git history does not reveal any such issue, then we should just remove that check entirely.
That extra check was introduced by to fix
I have opened in jemalloc to get clarification from them about their alignment guarantees. It would be nice if someone with more knowledge could chime in, in particular knowledge about where exactly that value of 16 for on x86-64 comes from. Cc
Possibly from here:
C has types with an alignment smaller than are supported in all contexts. AFAICT this includes the memory returned by any memory allocation function - not only , but also . The largest scalar type of C implementations needs to be supported in all contexts. On most platforms, this type is often which the requires it to have an alignment of 16, so on these particular platforms, will have an alignment requirement of 16 bytes. On these platforms, all memory allocation functions need to return memory aligned to a 16 byte boundary when called with a to be able to support the largest scalar type provided by the C implementation. Otherwise would return memory not suitable for storing a scalar type. However, if the memory allocation is smaller than the size of the largest scalar type, then it would be illegal to store it there, so the memory returned needs to only be properly aligned to be able to store the largest scalar type that would fit in that particular size. In practice, this means that for sizes up to , the alignment of the returned memory equals the size of the allocation rounded to the previous power of two (e.g. in a 5 byte allocation, you can at most fit a 32-bit scalar, so the allocation only needs 4 byte of alignment). And for sizes larger than , the alignment is at least (this allows storing, e.g., an array of s).


Question: use std::alloc::{Global, Alloc, Layout, System}; <del> /// Issue #45955. </del> <ins> /// Issue #45955 and #62251. </ins> #[test] fn alloc_system_overaligned_request() { check_overalign_requests(System)

In practice, the fastest thing you can do, is calling malloc if , because if malloc will return an alignment of at least rounded to the previous power of two, which is always satisfied (remember that must be a power of two, so if its smaller than size, it is at least the previous one). will do this without having to branch on any user provided alignment argument. That's precisely what that code is doing. The else branch is calling a "generic" which should be able to handle any user-specified alignment. The implementation of based on : appears to have the bug you mention, and should probably call or similar. I suspect that the implementation of provided by jemalloc, which we use here: doesn't have this issue, because it probably just forwards the call to , which supports alignment smaller than .
So basically on the C side, one assumes that is not used with types that use the C equivalent of ? With that assumption, I agree it is enough for to guarantee an alignment of rounded down to the next power of two. (I think your post originally said "up", but now it says "down" so I guess we agree.) That's what I and our implementation indeed handles that case just fine. The bug in the way we call is fixed by Still, it would be nice not to be able to reason about "in practice", but get some commitment from jemalloc -- see And finally, this only concerns on Unixes. Does anyone know what the situation looks like with on Windows? libstd currently assumes even small allocations to be aligned there, and agrees with that (Ctrl-F "on 64-bit platforms").
EDIT: C11 to C, but yes, malloc doesn't know anything about the alignment of a type. It still can be used, but the user needs to check whether the allocation is properly aligned. The docs are quite clear IMO: Anything more concrete than that will be target specific, and those details are outside jemalloc's control - if jemalloc wants to replace the system allocator in a target, it needs to comply with the ABI there. If it were to guarantee more, e.g., all allocations are 16byte aligned, it wouldn't work on platforms using the SysV i386 ABI.
Well, with that statement from the jemalloc docs is wrong, isn't it?


Question: use std::alloc::{Global, Alloc, Layout, System}; <del> /// Issue #45955. </del> <ins> /// Issue #45955 and #62251. </ins> #[test] fn alloc_system_overaligned_request() { check_overalign_requests(System)

And for users to manually do the alignment, getting something more concrete would be useful. And also for Rust! Currently you are deducing a whole lot of things from a few words in the spec. I have zero confidence that this is the only way to read the spec. So something like: "for we guarantee an alignment of ; for smaller sizes we guarantee an alignment of the size rounded down to the next power of two." would IMO be prudent to ask from the jemalloc devs. Or else we'll find ourselves with more bugs when someone interprets all this slightly differently.
I don't know how useful would that be: malloc only needs to comply with the C standard. Parts of it are implementation-defined, and what those are defined to is often specified by the system ABI. That's the only thing the global allocator can rely on. On most platforms, the system allocator - which is the default global allocator for Rust programs - is not jemalloc - it is the one from glibc, musl, microsoft, apple, google, mozilla, etc. In some platforms, like FreeBSD, the system allocator is jemalloc, but even there we can't exploit that knowledge because users can just and now the global allocator is a different one. That's an use case we support. So even if jemalloc were to offer extra guarantees here, Rust's system allocator cannot make use of them. The only places were we can can exploit jemalloc's specific guarantees, is when using crates like jemallocator, to explicitly hardcode the allocator to a particular one. As in, if that allocator is not linked, you get a linker error or similar. But even there, it makes sense to stick to what C and the platform ABI guarantees, because jemalloc is free to break anything else in the next version.
Well it would save us this entire discussion. If that doesn't demonstrate its usefulness I don't know what does.^^ I don't know what the "system allocator" is for Linux, but the one in glibc actually guarantees a 16-byte alignment on 64bit systems for all allocations. So by that standard jemalloc would just be incorrect.
The platform ABI guarantees that. What the malloc implementations guarantee is irrelevant.


Question: use std::alloc::{Global, Alloc, Layout, System}; <del> /// Issue #45955. </del> <ins> /// Issue #45955 and #62251. </ins> #[test] fn alloc_system_overaligned_request() { check_overalign_requests(System)

If glibc were to guarantee that all addresses are 32-byte aligned, there is no way in which we could exploit that information in the implementation of the system allocator, because the platform only requires 16-byte alignment, and it is valid to pick any allocator at run-time that satisfies that.
So there a document somewhere saying "for x86-64 bit, 16-byte alignment is guaranteed"? But that document contains an exception for small sizes, making s behavior legal?
Yes, there are documents containing the rules of what's legal, at least for Linux x8664. Those document allow an exception for small sizes. One API that uses those is , which requires the alignment to be at least , which is 8 on x86_64, and which allows you to allocate bytes, with a smaller alignment. I still have no idea what jemalloc has to do with any of this - your original question is about , and that has nothing to do with jemalloc. But yes, jemalloc exploits this behavior, to be able to satisfy 1 byte request, and return addresses that are 1 byte aligned. Otherwise each 1 byte request would consume 16 bytes of memory within a memory page.
A document that could be relevant is the C standard. Unfortunately, as mentioned in the commit message for , it is rather tautological on this topic: The standard does not give any numeric value. Like many other aspects of C, it looks like the actual value of is implementation-defined.
When using jemalloc, becomes jemalloc. That's how happened. Do you have a reference for something that concretely calls out an exception for small types? The C standard only does this very indirectly, as you showed.
That was a bug in our implementation of system that applies to pretty much all allocators, not only jemalloc. says (emphasis mine): Since the alignment of an object is a power of two that is always smaller than or equal to the object size, rounding down the alignment of an allocation to the previous power of two always produces an allocation properly aligned for every type that can fit it. That holds for all allocations, so there is no exception for that. That's the rule. Since that would mean that large allocations must be unreasonably aligned, the standard does provide an exception for allocations of size larger than than .


Question: use std::alloc::{Global, Alloc, Layout, System}; <del> /// Issue #45955. </del> <ins> /// Issue #45955 and #62251. </ins> #[test] fn alloc_system_overaligned_request() { check_overalign_requests(System)

These only need to be aligned at an boundary. If you believe this is incorrect, please show a counter-example for which this doesn't work.
AFAIK it is a normal way of using to make it override the symbol? Don't we still do that in rustc, or when using "jemallocator"? I don't say it is incorrect, I say it is awfully indirect. It's like reading tea leaves. I am looking for a clear definite statement. That doesn't seem to exist though. :( There clearly is some kind of "non-continuity" where all allocations are aligned MINALIGN except for small ones. Or vice versa, all allocations are aligned "size rounded down to power of 2" except for big ones. You are convincingly deriving that non-continuity from standard wording. I don't say you are wrong, but this feels like interpreting ancient scripture. A clear spec looks different. Also, an object of size 2 with alignment requirement 4 is "fundamental" according to your definition, and yet rounding down the size to the next power of 2 does not give the right alignment. So your rule does have exceptions, namely types marked .
Can you show such an object in C and/or Rust ? It's probably the most common way of switching allocators. What does is it requires to be linked to your binary, allowing (and making use of) jemalloc-specific APIs. If you do this, when using directly (not ), you can obviously rely on assumptions that only hold for . But cannot do that because, then it wouldn't work with other allocators.
The goal is not to rely on assumptions that only hold for . The goal is to make sure that we do not make assumptions that don't hold for . Because that's what we used to do, before got fixed. We were assuming something that was true for system but not for : that all allocations, no matter the size, are aligned. To make sure we don't do that again, I want to be sure that all assumptions we are making hold for . That's why I'd like jemalloc to spell out what we can assume.
Ah I forgot about the stride vs. size thing. So such an object does not exist.


Question: use std::alloc::{Global, Alloc, Layout, System}; <del> /// Issue #45955. </del> <ins> /// Issue #45955 and #62251. </ins> #[test] fn alloc_system_overaligned_request() { check_overalign_requests(System)

But such a exists, and it is something we want to support in our allocator API (we even have a test for that). And we do have objects with align size, namely all ZST.
Yeah, I agree. The only cases for which the "round to the previous power of two approach" doesn't work is for ZSTs, and types (or allocations) with align size. Since those just cannot happen in C, the C standard doesn't mention them as exceptions. That is, we can only call when that holds, and if it that doesn't hold, we need to call a different API that supports the align size case.


Question: discr_index, .. } => { <del> if !dest.layout.ty.variant_range(*self.tcx).unwrap().contains(&variant_index) { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> // No need to validate that the discriminant here because the // `TyLayout::for_variant()` call earlier already checks the variant is valid. </ins> let discr_val = dest.layout.ty.discriminant_for_variant(*self.tcx, variant_index).unwrap().val;

I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .


Question: if create_issue_for_status is not None: try: issue( <del> tool, create_issue_for_status, MAINTAINERS.get(tool, ''), relevant_pr_number, relevant_pr_user, LABELS.get(tool, ''), </del> <ins> tool, create_issue_for_status, MAINTAINERS.get(tool, ()), relevant_pr_number, relevant_pr_user, LABELS.get(tool, []), github_token, </ins> ) <del> except urllib2.HTTPError as e: </del> <ins> except HTTPError as e: </ins> # network errors will simply end up not creating an issue, but that's better # than failing the entire build job <del> print("HTTPError when creating issue for status regression: {0}n{1}" </del> <ins> print("HTTPError when creating issue for status regression: {0}n{1!r}" </ins> .format(e, e.read())) except IOError as e: print("I/O error when creating issue for status regression: {0}".format(e))

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: // stripping away any starting or ending parenthesis characters—hence this // test of the JSON error format. <del> #![warn(unused_parens)] </del> <ins> #![deny(unused_parens)] </ins> #![allow(unreachable_code)] fn main() { let _b = false; <del> if (_b) { </del> <ins> if (_b) { //~ ERROR unnecessary parentheses </ins> println!("hello"); }

Update test file to use + annotations instead of (see https://rust-) The files need to update are: - <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
is the correct file name , not ? And what about this comment?
Is the problem fixed ? If not, I would like to work on it !
WIP PR has been closed due to inactivity so you can work on this.
I would like to be assigned to this issue. Am I supposed to do a new pull request ?
claim Go ahead!
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
Hmm, it's odd, anyway, you can assign the issue to yourself by comment Ah, I mistaken the command, the collect one is , sorry.
claim
If I understood well the problem: I must replace all the by just , even if comment exist ? Because the output changes, I should modify the .stderr version I must change with in , and as should raise an error we add why add in the version ?


Question: ]).decode(sys.getdefaultencoding()).strip() llvm_sha = subprocess.check_output([ "git", "rev-list", "--author=bors@rust-lang.org", "-n1", <del> "--merges", "--first-parent", "HEAD", </del> <ins> "--first-parent", "HEAD", </ins> "--", "{}/src/llvm-project".format(top_level), "{}/src/bootstrap/download-ci-llvm-stamp".format(top_level),

An error message indicating that a full (or at least longer) git history is required. The correct link would include a commit hash inbetween the . But the required commit hash is not available because there is no full history. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, can I do this? label +A-rustbuild
Mentoring instructions: find what this command outputs when the repository is shallow: If it's an error, see if you can check for a shallow repository somehow and give a hard error instead of continuing onward just to fail.
Note that this shouldn't need to the full history of the repo, just the past few days, since PRs are constantly being merged.
We should only need one (bors merge) commit, I believe - each bors merge has the full set of artifacts.
The command prints nothing in my shallow clone. There is a bors merge commit in my shallow clone though: The command before used to work for me -- I was able to enable in my shallow clone. I tried to fetch more commits, and then started to work: But still prints nothing.
cc I would have expected the git log and git rev-list to be 'identical', in some sense, so perhaps that's something worth filing upstream as well. But regardless, I am inclined to revert to fix this issue; it was primarily a 'hopefully more robust' solution and to my knowledge wasn't actually fixing any known bugs, so since it caused a bug seems good to revert it for now...
I think it's possible that the shallow clone is causing the predicate to fail. Note the decoration in The git documentation implies that shallow clones use something akin to the (fake parentage for commits) facility for shallow clones. Maybe removing is sufficient? I'm a bit wary because bors seems to create non-merge commits on occasion (for squashes), but maybe it never does so on the first-parent history. I haven't had a chance to poke at a shallow clone in detail yet.
I'm seeing a similar problem for git worktrees, not just shallow clones. EDIT: this may have been a separate reason, it just had the right timing
Would love to see movement on this.


Question: ]).decode(sys.getdefaultencoding()).strip() llvm_sha = subprocess.check_output([ "git", "rev-list", "--author=bors@rust-lang.org", "-n1", <del> "--merges", "--first-parent", "HEAD", </del> <ins> "--first-parent", "HEAD", </ins> "--", "{}/src/llvm-project".format(top_level), "{}/src/bootstrap/download-ci-llvm-stamp".format(top_level),

I don't want to allocate ~20GB of laptop space to a deep clone of the repository in order to simply be able to build the compiler. When i was messing around, removing "--merges" as suggested did the trick.
feel free to make a PR with that change :)
I wasn't sure if there was some reason not to do that: I'm a bit wary because bors seems to create non-merge commits on occasion (for squashes), but maybe it never does so on the first-parent history. I don't really grok most of what said there, but if you think that's a safe change, then sure thing!
As long as we keep first parent, dropping merges should be ok, any commit in the first parent chain should have artifacts (if it's recent enough).
I would appreciate knowing details of what behavior you're seeing with git worktrees, if you're willing to provide them.
Sorry, I'm not seeing any related problem when trying to do a simple test with worktrees. I do see a problem with shallow clones. Could you please describe what you're seeing? Does it still happen if you delete the options from the command lines in ?
I don't think we need to exhaustively catalogue the issues - even if removing --merges doesn't fix all the issues it will fix some of them, and we can make more improvements in follow-ups.
claim
Someone should probably file a bug about failing to see merge commits in shallow clones. I don't feel like I understand the issue well enough to do so.


Question: ItemKind::Mod(..) if i.ident == keywords::Invalid.ident() => { return visit::walk_item(self, i); } <del> ItemKind::Fn(_, FnHeader { asyncness: IsAsync::Async { closure_id, return_impl_trait_id, }, .. }, ..) => { </del> <ins> ItemKind::Fn( ref decl, ref header @ FnHeader { asyncness: IsAsync::Async { .. }, .. }, ref generics, ref body, ) => { </ins> return self.visit_async_fn( i.id, <del> closure_id, return_impl_trait_id, </del> i.ident.name, i.span, <del> |this| visit::walk_item(this, i) </del> <ins> header, generics, decl, body, </ins> ) } ItemKind::Mod(..) => DefPathData::Module(i.ident.as_interned_str()),

suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.


Question: ItemKind::Mod(..) if i.ident == keywords::Invalid.ident() => { return visit::walk_item(self, i); } <del> ItemKind::Fn(_, FnHeader { asyncness: IsAsync::Async { closure_id, return_impl_trait_id, }, .. }, ..) => { </del> <ins> ItemKind::Fn( ref decl, ref header @ FnHeader { asyncness: IsAsync::Async { .. }, .. }, ref generics, ref body, ) => { </ins> return self.visit_async_fn( i.id, <del> closure_id, return_impl_trait_id, </del> i.ident.name, i.span, <del> |this| visit::walk_item(this, i) </del> <ins> header, generics, decl, body, </ins> ) } ItemKind::Mod(..) => DefPathData::Module(i.ident.as_interned_str()),

Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:


Question: ), .. }) => { <del> // We have a situation like `while Some(0) = value.get(0) {`, where `while let` // was more likely intended. err.span_suggestion_verbose( expr.span.shrink_to_lo(), "you might have meant to use pattern destructuring", "let ".to_string(), Applicability::MachineApplicable, ); </del> <ins> // Check if our lhs is a child of the condition of a while loop let expr_is_ancestor = std::iter::successors(Some(lhs.hir_id), |id| { self.tcx.hir().find_parent_node(*id) }) .take_while(|id| *id != parent) .any(|id| id == expr.hir_id); // if it is, then we have a situation like `while Some(0) = value.get(0) {`, // where `while let` was more likely intended. if expr_is_ancestor { err.span_suggestion_verbose( expr.span.shrink_to_lo(), "you might have meant to use pattern destructuring", "let ".to_string(), Applicability::MachineApplicable, ); } </ins> break; } hir::Node::Item(_)

I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim


Question: <ins> // Checks that there is a suggestion for simple tuple index access expression (used where an // identifier is expected in a format arg) to use positional arg instead. // Issue: <https://github.com/rust-lang/rust/issues/122535>. //@ run-rustfix fn main() { let x = (1,); println!("{0}", x.0); //~^ ERROR invalid format string } </ins>

<!-- While learning rust from the book i tried printing the second(.1) value in a tuple, and it broke the format string and wouldn't compile --I tried this code: I expected to see this happen: printing of the value 1. Instead, this happened: it gave the following error: if you intended to print , you can escape it using rustc <!-- 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. --:
Only printing an identifer is supported, arbitrary expressions are not: https://rust-
There's more discussion about this in or in many other places, it's a thing that keeps coming up.
The error message could be nicer, so I'll convert it into a diagnostics issue.


Question: impl<CTX> HashStable<CTX> for InferTy { fn hash_stable(&self, ctx: &mut CTX, hasher: &mut StableHasher) { use InferTy::*; <ins> discriminant(self).hash_stable(ctx, hasher); </ins> match self { TyVar(v) => v.as_u32().hash_stable(ctx, hasher), IntVar(v) => v.index.hash_stable(ctx, hasher),

The following code works in 1.56.0 but crashes 1.57.0 as well as the most recent nightly — . <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
According to cargo-bisect-rustc the regression is from — FYI regressed nightly: nightly-2021-09-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems that this is duplicate of and ; only triggers with incremental compilation enabled. Unfortunately although I authored the original PR, I don't know a lot about incr-comp or the query system to diagnostic the issue. label: +A-incr-comp
Found the bug, I'll put up a PR in a sec. claim
reopening as this is a stable-to-stable regression, and (I think) we keep those open until a fix lands on stable or we explicitly decline to fix.
was this backported / can we close the issue? :)
The fix was backported and released in 1.58.0
Perfect, thanks for checking !


Question: { let result = local_s .try_with(|s| { <del> if let Ok(mut borrowed) = s.try_borrow_mut() { if let Some(w) = borrowed.as_mut() { return w.write_fmt(args); } </del> <ins> // Note that we completely remove a local sink to write to in case // our printing recursively panics/prints, so the recursive // panic/print goes to the global sink instead of our local sink. let prev = s.borrow_mut().take(); if let Some(mut w) = prev { let result = w.write_fmt(args); *s.borrow_mut() = Some(w); return result; </ins> } global_s().write_fmt(args) })

I tried this code (using ): I expected to see this happen: The thread should've panicked with 'Index out of bounds: the len is 0 but the index is 0' Instead, this happened: Thread crashes with SIGILL (illegal instruction) This bug works in stable, beta and nightly. It also does the same in . Here is my (I figured that it might be useful given the nature of the bug). The bug doesn't appear if run from main, nor if run directly (without passing from the Display impl). : <details<summaryBacktrace</summary<prunning 1 test thread panicked while processing panic. aborting. error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: (signal: 4, SIGILL: illegal instruction) </p</details
This seems to be due to the . Using instead works fine.
I can reproduce. This seems to happen if LOCALSTDERR is initialized (e.g., with setpanic) which leads us to this . Note that the RefCell there is borrowed so that we can write to it, but then when we go to panic we try to temporarily . This borrows the RefCell mutably, again, leading to a panic. Since this happens within an existing panic, we abort the process. Smaller example:


Question: _ => tcx.def_span(item), }; try_visit!(visitor.visit(span, tcx.type_of(item).instantiate_identity())); <del> for (pred, span) in tcx.predicates_of(item).instantiate_identity(tcx) { </del> <ins> for (pred, span) in tcx.explicit_predicates_of(item).instantiate_identity(tcx) { </ins> try_visit!(visitor.visit(span, pred)); } } DefKind::TraitAlias | DefKind::Trait => { <del> for (pred, span) in tcx.predicates_of(item).instantiate_identity(tcx) { </del> <ins> for (pred, span) in tcx.explicit_predicates_of(item).instantiate_identity(tcx) { </ins> try_visit!(visitor.visit(span, pred)); } }

https://crater-
searched nightlies: from nightly-2024-02-01 to nightly-2024-03-20 regressed nightly: nightly-2024-02-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsprobably
WG-prioritization assigning priority (). label -I-prioritize +P-high
MCVE


Question: //     impl Foo for std::cell::Ref<u32> // note lack of '_ //     async fn foo(_: std::cell::Ref<u32>) { ... } LifetimeRibKind::AnonymousCreateParameter(_) => { <del> error = true; </del> break; } // `PassThrough` is the normal case.

I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.


Question: pub fn to_u16s<S: AsRef<OsStr>>(s: S) -> crate::io::Result<Vec<u16>> { fn inner(s: &OsStr) -> crate::io::Result<Vec<u16>> { <del> let mut maybe_result: Vec<u16> = s.encode_wide().collect(); </del> <ins> // Most paths are ASCII, so reserve capacity for as much as there are bytes // in the OsStr plus one for the null-terminating character. We are not // wasting bytes here as paths created by this function are primarily used // in an ephemeral fashion. let mut maybe_result = Vec::with_capacity(s.len() + 1); maybe_result.extend(s.encode_wide()); </ins> if unrolled_find_u16s(0, &maybe_result).is_some() { return Err(crate::io::const_io_error!( ErrorKind::InvalidInput,

The Unicode Windows API internally works with (potentially ill-formed) UTF-16 paths that must be converted to from Rust's UTF-8 strings. The conversion happens here: does the translation from WTF-8 to UTF-16, leaving a with . The following calling to will then allocate to reserve additional memory for the null-terminating character. This could be resolved in two ways: 1) Call beforehand and then call on EncodeWide. 2) Make a wrapper around that increases by one. Incorporating the final null byte into would add a performance penalty, therefore it would probably be desirable to just adjust the sizehint by one and adding the null-terminator manually. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
In the interest of enumerating possibilities, there's also using (hopefully this will optimize): Or we could test the for nulls before converting.
That's a good idea! Chain actually gives an example for windows paths: Although I'm not sure what's more efficient here, std::iter::once or [0]? Allocations are quite expensive so I believe the additional check (if it's not optimized away) would be worth it. However I also discovered a deeper issue. The sizehint that originates from the WTF-8 iterator is in UTF-32 code points. The lower bound will be (assuming that all code points are U+ or higher), the upper bound is (everything is "ASCII"). When collecting into a vector, the lower bound is chosen as an initial capacity. Since you almost never encounter paths that consists of U+ characters only, the estimated lower bound will always be too low and 4 allocations are required if the path is ASCII only, 2 allocations are required if the path is UTF-16 only, and 1 allocation is required if the path is UTF-32 only. It might be worth a consideration whether to call , as that would be a sane default (on the assumption that the majority of paths are UTF-8). However, this might waste some memory, do we have any idea on whether paths created from this function are primarily used ephemerally?
I believe all uses of are currently ephemeral.


Question: pub fn to_u16s<S: AsRef<OsStr>>(s: S) -> crate::io::Result<Vec<u16>> { fn inner(s: &OsStr) -> crate::io::Result<Vec<u16>> { <del> let mut maybe_result: Vec<u16> = s.encode_wide().collect(); </del> <ins> // Most paths are ASCII, so reserve capacity for as much as there are bytes // in the OsStr plus one for the null-terminating character. We are not // wasting bytes here as paths created by this function are primarily used // in an ephemeral fashion. let mut maybe_result = Vec::with_capacity(s.len() + 1); maybe_result.extend(s.encode_wide()); </ins> if unrolled_find_u16s(0, &maybe_result).is_some() { return Err(crate::io::const_io_error!( ErrorKind::InvalidInput,

We tend to use it only for as long as necessary to call a Windows API. There are a few places we keep wide strings around longer but those don't use as far as I can tell.
In light of that, I believe that the first solution would be the best. Solution number two would make naming very awkward (EncodeWideWithNul?). And while your solution is very elegant and correct, it would still mostly under-allocate given the interaction between size_hint's lower bound and collect. However, I find both solution 1 and solution 3 acceptable. It would be good to know how much reallocation actually costs and if it even matters at all in the context of interacting with expensive IO.
I do agree implementing solution 1 would be a good idea. Having some good performance numbers would be great but I do suspect reducing allocations would be a win here. I would also like us to use stack buffers more, similar to . and only use new allocations when necessary. But that's perhaps another issue.
Reducing via stack buffers is a good idea, but I think it's out of scope for this issue. For now let's just reduce regular allocations, that should already give us some improvement! I'll try to see if I can implement this one. claim
Fixed by


Question: return self.parse_if_expr(); } if try!(self.eat_keyword(keywords::For) ){ <del> return self.parse_for_expr(None); </del> <ins> let lo = self.last_span.lo; return self.parse_for_expr(None, lo); </ins> } if try!(self.eat_keyword(keywords::While) ){ <del> return self.parse_while_expr(None); </del> <ins> let lo = self.last_span.lo; return self.parse_while_expr(None, lo); </ins> } if self.token.is_lifetime() { let lifetime = self.get_lifetime(); <ins> let lo = self.span.lo; </ins> try!(self.bump()); try!(self.expect(&token::Colon)); if try!(self.eat_keyword(keywords::While) ){ <del> return self.parse_while_expr(Some(lifetime)) </del> <ins> return self.parse_while_expr(Some(lifetime), lo) </ins> } if try!(self.eat_keyword(keywords::For) ){ <del> return self.parse_for_expr(Some(lifetime)) </del> <ins> return self.parse_for_expr(Some(lifetime), lo) </ins> } if try!(self.eat_keyword(keywords::Loop) ){ <del> return self.parse_loop_expr(Some(lifetime)) </del> <ins> return self.parse_loop_expr(Some(lifetime), lo) </ins> } return Err(self.fatal("expected `while`, `for`, or `loop` after a label")) } if try!(self.eat_keyword(keywords::Loop) ){ <del> return self.parse_loop_expr(None); </del> <ins> let lo = self.last_span.lo; return self.parse_loop_expr(None, lo); </ins> } if try!(self.eat_keyword(keywords::Continue) ){ let lo = self.span.lo;

Rustc's parser does not include a loop's label in its span. So the span associated to the expression will contain only cc


Question: Abi::Aggregate { sized: true } }; align = align.max(niche_align); <ins> size = size.abi_align(align); </ins> return Ok(tcx.intern_layout(LayoutDetails { variants: Variants::NicheFilling {

<details<summaryBacktrace</summary</detailsWindows 10 (64-bit)
Which code had caused this assertion? Caused by this assertion: Which was introduced in , which is beta-nominated. cc
I'm glad I that assertion! What it likely means is that isn't a multiple of . I'd be quite surprised if and/or weren't involved.
In my case this error is caused by the crate. Simply including it in your and compiling crashes rustc. <details<summaryBacktrace</summary</detailsI'm on Arch running the latest nightly rustc.
Looks like triggers the assertion, and it has alignment but size (which is illegal), IIRC, includes some types that are ( this is indeed which has a packed ) and has caused issues in the past as well. EDIT: minimal repro:


Question: |                            ^ help: remove this semicolon error[E0601]: `main` function not found in crate `issue_49040` <del> --> $DIR/issue-49040.rs:1:29 </del> <ins> --> $DIR/issue-49040.rs:2:12 </ins> | <del> LL | #![allow(unused_variables)]; |                             ^ consider adding a `main` function to `$DIR/issue-49040.rs` </del> <ins> LL | fn foo() {} |            ^ consider adding a `main` function to `$DIR/issue-49040.rs` </ins> error: aborting due to 2 previous errors

Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.


Question: /// # Examples /// /// ``` <del> /// #![feature(mutex_unpoison)] /// </del> /// use std::sync::{Arc, Mutex}; /// use std::thread; ///

Feature gate: This is a tracking issue for functions to clear the poisoned flag on and . [x] [x] Implementation: [x] Final comment period (FCP) [ ] 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 comment period (FCP) is always needed before stabilization. This works as follows: A library API 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 comment 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.
Hi, I read (wich got automatically closed by the way) and the PR It seems all good. What is the next step to make it in the stable API ? Can I help somehow ?
Hi, sorry if flooding but are there any updates regarding this issue?
I think the next step is one of the rust developers needs to start the final comment period. IDK what the criteria for doing so are.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I was wondering whether the idea of had been considered and found that addressed it. SGTM!