Question: bug!("expected capture to be an upvar"); }; <del> assert!(child_capture.place.projections.len() >= parent_capture.place.projections.len()); </del> parent_base.var_path.hir_id == child_base.var_path.hir_id && std::iter::zip(&child_capture.place.projections, &parent_capture.place.projections) .all(|(child, parent)| child.kind == parent.kind)

This bug only happens when calling a method on two different referenced variables inside an async closure. For some reason, this bug will not happen if the lines are flipped (calling it on test first then temp). It also will not happen if test isn't cloned outside the closure first. This will error: This will not: Neither will: Nor will: But if both the order is flipped and the line order is flipped it will crash (variable name changed to make sure shadowing wasn't the issue): This setup for the bug was found entirely through trial and error. The original issue was found in a nightly build of a project I'm working on (). This bug was introduced in the latest version of nightly (2024-04-08). It was not present in 2024-04-07. rustc 1.79.0-nightly ( 2024-04-08) binary: rustc commit-hash: commit-date: 2024-04-08 host: x8664-pc-windows-msvc release: 1.79.0-nightly LLVM version: 18.1.3 ICE txt file:
thank you for producing these examples; they're very helpful. i will have a fix out tomorrow, sorry for the inconvenience and hope it doesn't discourage you from testing async closures more.
Wow, that was quick! Thanks, I'll make sure to report any more I come across, I plan on implementing more async closures into the project with my next big refactor because of how helpful they are.


Question: span: Span, self_expr: &'tcx hir::Expr<'tcx>, call_expr: &'tcx hir::Expr<'tcx>, <ins> skip_record_for_diagnostics: bool, </ins> } impl<'a, 'tcx> Deref for ConfirmContext<'a, 'tcx> {

<!-- 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. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: rm_rf(&build.out.join("tmp")); rm_rf(&build.out.join("dist")); rm_rf(&build.out.join("bootstrap")); <ins> rm_rf(&build.out.join("rustfmt.stamp")); </ins> for host in &build.hosts { let entries = match build.out.join(host.triple).read_dir() {

Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at


Question: #[rustc_builtin_macro] #[macro_export] #[rustc_diagnostic_item = "assert_macro"] <del> #[allow_internal_unstable(panic_internals, edition_panic, generic_assert_internals)] </del> <ins> #[allow_internal_unstable( core_intrinsics, panic_internals, edition_panic, generic_assert_internals )] </ins> macro_rules! assert { ($cond:expr $(,)?) => {{ /* compiler built-in */ }}; ($cond:expr, $($arg:tt)+) => {{ /* compiler built-in */ }};

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Note that is not marked as internal I expected to see this happen: code compiles Instead, this happened: ` Maybe the lint should ignore code from expansions? <!-- 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. --:
On , the expansion of with contains a call to : is tagged with , but not .


Question: use syntax::visit; use syntax::visit::Visitor; <del> // An error has already been reported to the user, so no need to continue checking. </del> <ins> // Useful type to use with `Result<>` indicate that an error has already // been reported to the user, so no need to continue checking. </ins> #[deriving(Clone,Show)] pub struct ErrorReported;

cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.


Question: <del> Subproject commit 01c8b654f9a01371414d1fd69cba38b289510a9e </del> <ins> Subproject commit 2b9078f4afae82f60c5ac0fdb4af42d269e2f2f3 </ins>

Tracking issue: . The assembler directive allows to treat data as instructions. This allows to generate CPU instructions that are otherwise not possible using assembler commands. It is platform specific and mostly relevant for RISC-V platforms, but I could also find uses for it on MIPS targets as well. More generally speaking, any solution that allows me to produce custom machine code instructions without a performance overhead will be okay for me. The current best workaround is to write the assembler code externally and then link to it. However, this adds the overhead of a function call that cannot be inlined due to the FFI boundary, so this is not acceptable in the long term. See also for some more discussion of my problem.
This will likely work automatically once LLVM supports it. A commit has recently landed () but is not yet in any released version.
label +A-inline-assembly +F-asm
I tried building rust+cargo from source with cherry-picked. Sadly it did not make the error message go away. A good way to check is to use on a minimal example instead. Turns out that I somehow wasn't.
Okay, it actually does work. What is the procedure around Rust's LLVM dependency? How often is it bumped? Is this a candidate for cherry-picking onto rust-llvm?
LLVM procedure is at https://rustc-dev- I think this is a candidate for cherry-picking but someone needs to do the work.


Question: assert::<Box<T>>(); assert::<Vec<T>>(); assert::<RefCell<T>>(); <ins> assert::<AssertRecoverSafe<T>>(); assert::<&AssertRecoverSafe<T>>(); assert::<Rc<AssertRecoverSafe<T>>>(); assert::<Arc<AssertRecoverSafe<T>>>(); </ins> } }

Test Case 1: Test Case 2: Both produce errors like this: CC
Hm, so the first case here should work (e.g. should subvert basically everything), although the second case is correct in yielding an error (albeit not a very good one)
Is the second case not allowed then? 's documentation suggests that manually implementing it is okay to do: I figured only existed to wrap types which you couldn't yourself, but for which you can ensure their invariants are upheld across the boundary. And what about moving values into the closure? can't be unwrapped, at least not currently.
Oh wait sorry I misread your second example, I failed to notice the manual ! This is basically a case where closure captures are coming into play. The closures aren't annotated with , so outer variables are captured by-reference which means that the actual types being tested against the trait here are and . In the first case that should be handled by , but the second is legitimately indicating that it's not a recover-safe type (b/c the reference is different than the by-value). You should be able to get around this via either plus or via . Certainly an interesting interaction going on here though. One would likely expect that if isn't recover safe that would fix the problem but it's likely what you really need to do is due to the way closures largely work.
There's , why not ? Coherence?
Nah unfortunately that'd defeat the purpose of the distinction. The type is itself recover safe, it's just that's not (so the distinction need to be there)
It's unfortunate that fails due to coherence or something like that:
Hm interesting, I guess yeah you'll be forced to move the reference inside the wrapper rather than having a reference to the wrapper
Is it possible to implement then? My use case can contain and friends but I'm guaranteeing that they're unobservable in user code after recovery because I immediately re-panic after escaping the FFI stack.
I guess I can just use once it's fixed :stuckouttongue:. I see your PR has been accepted so I'll look forward to trying it on tonight's nightly. When do the buildbots fire?
Yeah currently you can implement (being renamed to ) I believe (although I can't say I've tried). For now though yeah I'd recommend just using plus closures.


Question: assert::<Box<T>>(); assert::<Vec<T>>(); assert::<RefCell<T>>(); <ins> assert::<AssertRecoverSafe<T>>(); assert::<&AssertRecoverSafe<T>>(); assert::<Rc<AssertRecoverSafe<T>>>(); assert::<Arc<AssertRecoverSafe<T>>>(); </ins> } }

The PR is in but'll take a few hours at least to land.
the problem with moving at this point in time is that I call in different branches of a but I pass the same closed-over value to it; I can't do the branch in the closure because I need to do some FFI cleanup afterwards regardless of whether a panic happened or not (which also requires the closed-over value). It would help if derived and/or so I could reuse it without constructing a new value for each arm, but that would probably require some discussion because I don't know if it's safe or not. I'll probably just implement and fix the name after your PR drops. A quick check confirms that it works just fine. Thanks anyways!
Oh yeah we could totally add more traits like and to , there shouldn't be any safety concerns there.
Updating code to modern functions and traits in makes this compile, so I'm going to close.


Question: rc::Rc, }; <ins> use std::time::Duration; //~^ ERROR expected item, found `require` use std::time::Instant; //~^ ERROR expected item, found `include` </ins> pub use std::io; //~^ ERROR expected item, found `using` fn main() { let x = Rc::new(1); let _ = write!(io::stdout(), "{:?}", x); <ins> let _ = Duration::new(5, 0); let _ = Instant::now(); </ins> }

I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!


Question:
See the specification for the [GitHub Tables extension][tables] for more details on the exact syntax supported.  ### Task lists Task lists can be used as a checklist of items that have been completed. Example: ```md - [x] Complete task - [ ] IncComplete task ``` This will render as

<input type="checkbox">

<input type="checkbox" checked>

 See the specification for the [task list extension] for more details.  [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.


Question: // #[repr(simd)], even if we don't actually use this struct directly. // // FIXME repr(simd) broken on emscripten and redox <del> // It's also broken on big-endian powerpc64 and s390x.  #42778 #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox", target_endian = "big")), repr(simd))] </del> <ins> #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox")), repr(simd))] </ins> struct Block(u64, u64, u64, u64); struct UnalignedBlock(u64, u64, u64, u64);

Trying to natively build powerpc64 as of , I get an ICE in stage 1:
FWIW beta () builds fine. I'll see if I can bisect it.
I seem to be hitting unrelated issues when bisecting, so it may be regressing in and out lately... It still ICEs on powerpc64 as of . I found that powerpc64le builds fine though, so this could be a general big-endian issue. If I get time I'll try s390x. Also, the reported region sometimes changes, though still the same location. Most often I get: error: internal compiler error: Region parameter out of range when substituting in region 'b (root type=Some((&&'b str,))) (index=1) But a few times I've seen: error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=Some((str::pattern::StrSearcher<'a, 'b,))) (index=0) And the backtraces are still useless...
Could you post the results of ?
That's doing a rebuild from the working dir of my prior attempts, so the only interesting piece is the stage1 libcore that ICEs. If you want the log of a complete build from scratch, I can get that too.
I'm seeing a different error: Could you compile with debuginfo to get a backtrace? That's the setting in
Fresh build directory, debuginfo enabled: error: internal compiler error: Type parameter (T/0) out of range when substituting (root type=Some((&mut [T], _))) substs=[] Same dir just building again: error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=Some((str::pattern::StrSearcher<'a, 'b,))) (index=0)
Very odd. rustc compiled on x86-64 (both a rustc I hand-compiled and the official nightlies) works without any problems, but rustc compiled on powerpc64 crashes with all sorts of random errors. I wonder whether there is some sort of LLVM bug - the next beta uses LLVM 4.0.1, so I should check whether that fixes things.


Question: // #[repr(simd)], even if we don't actually use this struct directly. // // FIXME repr(simd) broken on emscripten and redox <del> // It's also broken on big-endian powerpc64 and s390x.  #42778 #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox", target_endian = "big")), repr(simd))] </del> <ins> #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox")), repr(simd))] </ins> struct Block(u64, u64, u64, u64); struct UnalignedBlock(u64, u64, u64, u64);

Also, there shouldn't be any LLVM IR differences between a rustc compiled on powerpc and a rustc compiled on x86, so maybe I could do a diff
We've seen weird differences between cross- and native-compiled rustc before for big-endian machines, which seems confirmed by powerpc64le working fine here. I'm still trying to get s390x access... cc who has found a few of these.
The usual problem is that cross-compiled and native-compiled metadata end up being incompatible, so an x86-built ppc64 libcore is incompatible with a ppc-built ppc64 libcore. Through maybe we've ended up in a case where ppc can't decode its own metadata.
Yes, my first suspect would be endianness issue. It could be fairly plausible that the metadata decoder is correct, but the encoder is not, hence the bug showing up on ppc-built stuff only.
I got an s390x build, and it fared even worse. Tons of move errors on types like this: before it finally ICEd: thread 'rustc' panicked at 'assertion failed: (Qualif::MUTABLEINTERIOR)', I'm guessing that these particular errors and ICEs are not significant in themselves, only as signs of some more general corruption.
Oddly enough, if I use an x86 stage0 to compile a powerpc stage1, or an powerpc stage0 to compile an x86 stage1, everything works fine, but if I use a powerpc stage0 to compile a powerpc stage1, the powerpc stage1 created is broken.
I can't figure out a good way to debug this without a powerpc computer. So I'm gotta leave this alone unless anyone's going to help me track it down (e.g., ssh access to a fast(!) powerpc computer).
I don't know if I can provide any machine access -- I'll check -- but I will keep working on this myself. Any tips for how to approach this? I tried valgrind, but I got so many errors that I think either I'm using it wrong or that build is just hopelessly broken.
Bisecting took me to 's merge commit . The parent commit builds fine. I didn't drill down into the individual commits for that PR, as it just seems to be iterating different ideas.


Question: // #[repr(simd)], even if we don't actually use this struct directly. // // FIXME repr(simd) broken on emscripten and redox <del> // It's also broken on big-endian powerpc64 and s390x.  #42778 #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox", target_endian = "big")), repr(simd))] </del> <ins> #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox")), repr(simd))] </ins> struct Block(u64, u64, u64, u64); struct UnalignedBlock(u64, u64, u64, u64);

If you look on master, also moved that code to to use in more places. I don't know what that code would have to do with endianness or cross-compiling weirdness per se, but I do worry about the memory alignment of these: Later the temp block gets cast to , as do the input pointers in the first place, which would seem to imply that alignment won't matter. But if is still having an effect as stated, then I worry that perhaps the extra alignment constraints are just being assumed in the code generated to move between , , and . The input could have a smaller alignment than .
I replaced with a naive byte-byte swap on master, and it works! Now to figure out the right fix...
Just removing that gets a working build! Regarding endianness and cross-compiling, could there be a bug in the way the simd type is translated to LLVM? Especially since it's being seen through a pointer. I'm going to do some comparisons of the builds with and without that . if it would help, I could share those builds somewhere for you to grab.
cc since I'm blaming your PRs...
Affects both powerpc64le and powerpc64 in Debian now: Correction, the latest upload for ppc64 builds fine:
The Debian bug is little-endian not big-endian. This bug is the other way around, and is very old.
Right, the failure on big-endian was a different one for the previous 1.30 upload to experimental.
Er for the record, no the previous beta-7 was also problematic for little-endian but OK for big-endian - the big-endian one , otherwise it would be fine (20 test failures). Anyway we have some clues on the other bug, more comments there.
Isn't this bug fixed by ? - i.e., what is the Rust situation on powerpc?
This is likely fixed. Rust 1.32.0 succeeded on ppc64el, see
This bug is on big-endian, the link you pasted is little-endian, but if you remove the "el" at the end of the URL you get to the big-endian results which are also OK. We do things slightly differently from Fedora though.
do you know what the status on Fedora is?
It was "fixed" by by disabling SIMD in that function -- not really a satisfactory solution IMO.


Question: // #[repr(simd)], even if we don't actually use this struct directly. // // FIXME repr(simd) broken on emscripten and redox <del> // It's also broken on big-endian powerpc64 and s390x.  #42778 #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox", target_endian = "big")), repr(simd))] </del> <ins> #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox")), repr(simd))] </ins> struct Block(u64, u64, u64, u64); struct UnalignedBlock(u64, u64, u64, u64);

So in that sense, we don't have any issue on Fedora any more. But perhaps we should see what happens to codegen these days if we revert that and try allowing SIMD there again. edit: to be clear -- I will try changing that back myself to see what happens.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

According to the , "The four octets are in decimal notation, divided by . (this is called 'dot-decimal notation'). Notably, octal numbers and hexadecimal numbers are not allowed per IETF RFC 6943"; however the parsing of the violates the "strict" form mentioned in —this form is what prohibits octal and hexadecimal numbers—meanwhile the conforms to it. IETF RFC 6943 Section 3.1.1. states: If the af argument of inetpton() is AFINET, the src string shall be in the standard IPv4 dotted-decimal form: where "ddd" is a one to three digit decimal number between 0 and The inetpton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inetaddr() accepts). As shown above, inetpton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AINUMERICHOST flag is passed to it. I tried this code: I expected to see this happen: both s not causing a panic since the first has an octet represented by more than three base-10 numbers despite the requirement per RFC 6943 stating each octet be a "one to three digit decimal number". The second is valid per RFC 6943 since it is a string of exactly 4 octets separated by where each octet is a "one to three digit decimal number". Instead, this happened: Both lines cause a panic. : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I believe that the second input () is not valid, since the spec explicitly says that octal numbers are disallowed, and is an octal number in the loose form. The example in the RFC for an octal number is , which parses to if you use octal, but if you use decimal. If you instead have it parse it always as , that means that bad things can happen, such as different tools interpreting as different things.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

If you read the source code where the ipv4 address is parsed, it specifically disallows that: Regarding , the documentation only says that the disallowing of hexadecimal and octal numbers are according to IETF RFC 6943, and does not say anything about only allowing three digits. Also, four or more zeroes are an edge case, and thus the only numbers that can be parsed there with more than three digits, due to the disallowing of octal numbers apart from .
From the :
I'm confused by these comments. Padded zeros is not unique to the base-8 numeral system. Base-2, Base-3, etc. all have the property of having an infinite number of padded zeros with the convention being to truncate them all. After all is also valid in base-8, base-9, etc. The documentation is quite clear that the octets are to be interpreted in base-10 though, so this problem of how to interpret the octets is solved. Consequently the last octet in is interpreted as 1 in base-10 for the same reason the first octet in is interpreted as 127 in base-10 and not some other value (e.g., 87 in base-10) namely because the documentation says so. After all objecting to on the grounds that the last octet could be in base-8—again, all of the octets there could be in base-8—doesn't apply to the fact that is also rejected by the parsing algorithm since clearly each of those octets are not in base-8 since is not a symbol in the base-8 numeral system. This is of course nothing more than a consequence of incorrectly assuming padded 0s means base-8. The inconsistent treatment of 0 (in base-10) is also a consequence of this incorrect assumption. Why is 0 (in base-10) allowed to be represented by one or more s, but 1 (in base-10) cannot have padded s? There is nothing special about the syntactic representation of 0 (in base-10) that warrants this inconsistent treatment. To me the solution is clear: more strictly follow IETF RFC 6943 and enforce that each octet be one-to-three digits in length.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

One could even follow a stricter format and require that there be no padded s at all—since the RFC doesn't actually specify that. This would then lead to consistent behavior (that's also more easily predictable since it follows a well-established convention) in that both and will either be accepted (since they both follow RFC 6943) or rejected (if a stricter form is required that requires the minimal number of digits necessary to represent each octet).
This is not an incorrect assumption, as octal numbers in the loose format are specified by the number having a leading zero. (See for the PR that banned octal numbers) This is an implementation detail in the way that it checks for leading zeroes: it checks if the number starts with a zero and rejects it if the resultant parsed number is not zero.
So we are re-defining how mathematics defines numeral systems? Saying that is in base-8 (i.e., octal) because of the leading makes no sense since none of those symbols except exist in that system. Rust certainly doesn't treat the in base-8 here: . Also the documentation clearly states that each octet is in "decimal notation". Suddenly treating the octet as base-8 is a clear contradiction to the documentation.
Using leading zeros to designate octal literals is a fairly common convention. In other languages like JS and C, . Rust doesn't have that as an octal prefix because it is confusing. When using leading zeros to indicate octal numbers, isn't a valid number at all (in the same way that isn't a valid base-10 number).
So it sounds like the documentation needs to be modified. It is confusing (because it is contradictory to reality) to say that each octet is in decimal notation when the actual implementation requires each octet to be either base-10 or base-8 where the latter is assumed when there are leading s and the value is not 0—at which point any positive-integer amount of s are allowed—and furthermore error when any octet is interpreted as base-8. Seems much easier to both document and comprehend to simply require at most 3 decimal digits for each octet and either forbid leading s (including for the integer 0) or allow leading s (including ).
"The actual implementation" is relevant only insofar as its behavior is externally observable.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

And -- correct me if I'm wrong -- in every case where the function succeeds, it (behaves as if it) interprets all digits in decimal, right? So I'd say it is correct to say that everything is "in decimal notation". The only weird bit is that is accepted, but is not. This is strange, but not in contradiction with saying things are "in decimal notation".
When the documentation says the "four octets are in decimal notation", that is effectively a definition which in turn can be phrased as a logical biconditional. In this case, the logical biconditional I formed in my head was something like: "a will be parsed into an iff it is a sequence of exactly 4 base-10 numbers delimited by a ". Only one of those directions is true: if an is produced from parsing a , then the was a sequence of exactly 4 base-10 numbers delimited by a . The other direction, which is observable via a parsing failure, is not true as can be seen with something like . That is a sequence of exactly 4 base-10 numbers delimited by a , but it leads to a parsing failure. As was discovered in the discussion , it sounds like "decimal notation" as used in the documentation is not what it has meant my entire life nor what it means in a lot of areas in Rust. Specifically, any number that has leading s is not a base-10 number but in fact a base-8 number. With this modified definition of "decimal"; then my counterexample, , is in fact not a counterexample since each of those octets are not in "decimal" notation but in fact base-8. Even more perplexing as stated by is that "a lone 0 is technically octal as well in C, not that it matters" which means the definition of "decimal" used in the documentation is neither the mathematical definition nor the C definition—since something like is successfully parsed despite each of those octets being in base-8 per the C definition.
That's true in C. (Specifically, it is how C converts series of digits to numbers. "Numbers" don't have leading 0s, numbers are elements of the set of integers. The representation of a number as a string of digits can have leading 0s.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

At least that's how I think the term is usually used when one needs to be precise about series of digits vs. the thing they represent.) However, it's not true for this function. Any number that has leading 0s is rejected by this function. This fact about C was brought up only to explain why leading 0s are rejected. No base-8 occurs anywhere in the behavior of this function. If you disagree, please show an input-output pair for this function which demonstrates that base 8 is used. (The code inside the function doesn't matter, of course. Only its observable behavior does.) I really don't understand why you keep insisting that this function has anything to do with base 8. I think it might be because of some quirk in how it is implemented, but unobservable implementation details are irrelevant. As a mathematician you should be even more used to this than most programmers, since the usual way of defining mathematical functions consists entirely of input-output pairs, there is not even such a thing as an "implementation"... but I am digressing. ;) Even mathematically speaking, the sequence of digits "0" represents the same number in any base system. So, in a very precise formal sense, "not that it matters" is accurate. A base is just a way to convert a series of digits into a number, and for series of digits consisting only of 0s, the result is always the same. The definition of "decimal" used in the documentation exactly matches the mathematical definition. The documentation just fails to mention that there is an additional restriction, namely that no leading 0s are accepted (except if all digits of an octet are 0). However, it remains the case that if an input is accepted by this function, then all octets are interpreted as decimal -- and moreover, all decimal representations without leading 0s are accepted by this function.
Saying a definition matches exactly with another definition before subsequently changing the definition by adding other restrictions does not make sense to me. Does the definition of an even integer "match exactly" with the definition of an integer? No. Adding or removing restrictions to a definition changes the definition. So the fact that leading s is not allowed means we are not talking about mathematical base-10.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

If I define a function that takes an integer and it errors any time the integer is not even; however the documentation of that function makes no mention of that seems very problematic. I would not defend such documentation by saying "my definition of integer matches exactly with the definition of the mathematical definition of an integer except I also require the integer to be divisible by 2". My documentation should very clearly define what I mean by "integer", or better, simply state "even integer".
Okay, I guess I should have said that it is strictly a restriction of the mathematical definition (a subset, if you take the graph view of a function). But it doesn't disagree on any inputs where it is defined. Your talking about base 8 makes it sound like sometimes it is not matching the base 10 function even when it does produce a result (but matches the base 8 function instead), and it took a quite a lot of time to realize that is not what happens. Moreover, the subset still contains the full graph of the inverse of the full "base 10" function where you always pick the shortest representation (i.e., the most common "serialization" function of numbers into base 10 representation). So unlike your "even" example it is a pretty reasonable parsing function still. There are only some "non-canonical" representations being rejected.
Well, I think we are talking in circles at this point honestly, lol. While I would agree my example is a more extreme example of documentation failure since conflating the definition of "even integer" with "integer" is more absurd than conflating the definition of "base-10 in the shortest representation (with the exception of 0 which is allowed any non-negative integer amount of leading 0s)" with "base-10", both examples suffer from the fact that additional failures occur than otherwise would occur based on the exact definition of the term that is used (in my example "integer" and in this example "decimal"). For me, as I mentioned in the other discussion, this really is not me being "pedantic". I wrote code based on the documentation that ended being invalid since I (mis-)interpreted "decimal" to be more general than what it actually means in this context.


Question: *slot = p.read_separator('.', i, |p| { // Disallow octal number in IP string. // https://tools.ietf.org/html/rfc6943#section-3.1.1 <del> match (p.peek_char(), p.read_number(10, None)) { (Some('0'), Some(number)) if number != 0 => None, (_, number) => number, } </del> <ins> p.read_number(10, Some(3), false) </ins> })?; }

Ideally, in my opinion at least, that should not happen especially since it is not that much additional effort to more properly document what certain terms mean even if that means just adding one or two more examples highlighting parsing failures (or successes) that one (like myself) would not expect.
We already agree that the docs need to be improved. :) The rest of this discussion is then mostly philosophical and not going to lead to a productive outcome, so maybe we better stop it. ;)


Question: key!(exe_suffix); key!(staticlib_prefix); key!(staticlib_suffix); <del> key!(os_family = "target_family", optional); </del> <ins> key!(os_family = "target-family", optional); </ins> key!(abi_return_struct_as_int, bool); key!(is_like_osx, bool); key!(is_like_solaris, bool);

Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)


Question: <ins> error[E0277]: the trait bound `for<'a> &'a _: Trait` is not satisfied --> $DIR/issue-89333.rs:6:5 | LL |     test(&|| 0); |     ^^^^ the trait `for<'a> Trait` is not implemented for `&'a _` | note: required by a bound in `test` --> $DIR/issue-89333.rs:11:55 | LL | fn test<T>(arg: &impl Fn() -> T) where for<'a> &'a T: Trait {} |                                                       ^^^^^ required by this bound in `test` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </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. --When creating this I found that it did not error if the function was not called and it also seemed to require it to be a function not just an argument of type T or (from what I tested) a different impl Trait although it could be any Fn* trait <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This appears to only happen on nightly while stable and beta generate useful error reports <!-- 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 --
label regression-from-stable-to-nightly
does not ICE but errors correctly while does ICE
glacier ""
searched nightlies: from nightly-2021-09-17 to nightly-2021-09-18 regressed nightly: nightly-2021-09-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsThat's , so cc
I've got this. claim Interestingly, this is precisely the kind of thing that is hopefully going to help harden against: "hidden" s when calling and such
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,

The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,

While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,

When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.


Question: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,

As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)


Question: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

rustc+cargo 1.40.0 Debian testing packages report the following ICE (which does not go away after a cargo clean): It can be reproduced by trying to build against
Can you try this on nightly?
Once the ICEBreakers-CleanupCrew is announced (which I think will be happening very soon), we should advertise this bug on it (at least the reduction to MCVE part of it); see
triage: P-high for initial investigation (i.e. identifying actual severity), removing nomination.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
Note that when I had a go at building on my Mac laptop, it failed with this message: This is due to in the source crate: So if you are on a Mac laptop, it may or may not be worth your effort to investigate this. (It is probably easy to work around, but I figure I'd let people know up front.)
Oops, right, you'll want to just drop that line. It shouldn't have any other effect, its only there due to (at least previously, based on my super-cursory read) libstd calling regular fsync() on OSX, which historically, well, didn't fsync.
I looked at this a bit more. I see the ICE on stable and beta. I do not see the ICE on nightly.


Question: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

On nightly, I instead get the following error: <details<summaryClick here to see error diagnostics</summary</details
Possibly associated: Possibly associated: I am not seeing the ICE in: searched nightlies: from nightly-2019-10-01 to nightly-2019-11-01 regressed nightly: nightly-2019-10-08 searched commits: from to regressed commit: source code: built against <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</detailssearched nightlies: from nightly-2019-11-01 to nightly-2020-01-31 fixed nightly: nightly-2019-12-08 searched commits: from to fix commit: source code: built against Possibly here: -
Reduced for in the crate (still depends on ):
This is happening somewhere in item-bodies checking, if I remove the body of with the error goes away.
Ok, I don't have more time to spend on this, I pushed some deletions to
Got it down to two files, but they have to be in different crates: : :
A little smaller: : : <details<summarybacktrace</summary</details
This is a duplicate of , judging by the error message and the fact that I just confirmed as the fixing commit for the reduced example that I created over there. modify labels to -E-needs-mcve.


Question: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:


Question: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.
intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.
That's not the problem, really, I believe we already have code to generate the shims. The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.
I don't think we have code for creating the shims, even. It's more that the ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.
We haven't had code for generating shims around intrinsics for a long time. As alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.
No longer ICEs ()
It requires now.
Ah, ok. Still no longer ICEs, but fails with a linker error (), if the distinction matters.
I think this has been fixed -- marking as E-needstest. Did you mean to self-assign this?
This seems like it could be made into an easy issue for newcomers.
This is now caught by .


Question: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

rustc just crashes with no useful errors. I guess you're not supposed to be able to do this anyway and it works if either are const instead of static but it shouldn't crash. Tested with latest nightly and 1.0.0-beta.2 on windows 64-bit.
No longer crashes:
E-needstest.
Triage: not aware of any tests being .
It seems that the E0394 error was removed in and the tests were moved from compile-fail and ui/error-codes to run-pass.


Question: } } <del> #[derive(Copy, Clone, PartialEq, Decodable, Encodable, Hash, HashStable_Generic)] </del> <ins> #[derive(Copy, Clone, PartialEq, Eq, Decodable, Encodable, Hash, HashStable_Generic)] </ins> #[rustc_pass_by_value] pub enum Variance { Covariant,     // T<A> <: T<B> iff A <: B -- e.g., function return type

Originally posted by in , see that PR discussion for more detail <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still looking into this? If so, please reassign yourself
claim


Question: display: table; } .stab { <del> border-width: 1px; border-style: solid; </del> padding: 3px; margin-bottom: 5px; font-size: 90%;

Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.


Question: display: table; } .stab { <del> border-width: 1px; border-style: solid; </del> padding: 3px; margin-bottom: 5px; font-size: 90%;

Making them less visually prominent, such as by reducing their contrast and making the warning just plain unstyled text, perhaps in the same place that stability information goes (though see for discussion on that), would help out a lot.
I would prefer this option. One benefit of showing the unstable APIs is that it invites people to test them, so having an opt-in for the curious would be good.
I would prefer an opt-out to an opt-in, that is, keep what we do today, but provide the ability to hide it if desired.
After spending some more time browsing the docs with an eye out for things that are visually distracting or attention grabbing, another option would be to just use a less attention grabbing way to denote unstable and deprecated items. Right now, they each use an extra, brightly colored box that makes them take up more visual space on the screen than stable items. On module index pages, they are actually made less prominent; they are sorted to the bottom, and made lower contrast with the background. This helps make them less attention catching, rather than more attention catching. But when browsing the methods provided on a struct or trait, they come with the big bright warning boxes that make them stand out more. I think I would still have a slight preference for having them hidden by default and just making the nightly docs easier to discover, such as having a version chooser in the header or sidebar, because of the issue mentioned in about docs of unstable items potentially being out of date. But making them less visually prominent rather than more visually prominent would help a lot.
I agree that the better way to solve this is by (perhaps) reducing the prominence of the "nightly-only" box. I don't think we should hide unstable items in the stable rustdoc generated at If someone is reading code that uses an unstable method, there's a good chance they will go to look it up in the stable docs. It would be a frustrating and confusing experience to not be able to find the method in the docs. It's a much better experience to find the method and be informed it's nightly-only / unstable. We probably don't want to reduce the prominence too much, though. If someone's looking for a method to call, it's pretty important that they notice when it's nightly-only. If they're working on a stable crate, that may mean they're not able to use the method at all.
Candidate PR at


Question: <ins> error[E0308]: mismatched types --> $DIR/dont-record-adjustments-when-pointing-at-arg.rs:26:37 | LL |         ns_window.setFrame_display_(0); |                   ----------------- ^ expected `()`, found integer |                   | |                   arguments to this method are incorrect | note: method defined here --> $DIR/dont-record-adjustments-when-pointing-at-arg.rs:5:8 | LL |     fn setFrame_display_(self, display: ()) {} |        ^^^^^^^^^^^^^^^^^       ----------- error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: let mut _5: &mut [u8; 1024];         // in scope 0 at $DIR/simple.rs:6:10: 6:18 let mut _6: &mut [u8; 1024];         // in scope 0 at $DIR/simple.rs:6:10: 6:18 scope 1 { <del> -         debug buf => _2;                 // in scope 1 at $DIR/simple.rs:5:9: 5:16 +         debug buf => _0;                 // in scope 1 at $DIR/simple.rs:5:9: 5:16 </del> <ins> debug buf => _2;                 // in scope 1 at $DIR/simple.rs:5:9: 5:16 </ins> } bb0: { <del> -         StorageLive(_2);                 // scope 0 at $DIR/simple.rs:5:9: 5:16 -         _2 = [const 0_u8; 1024];         // scope 0 at $DIR/simple.rs:5:19: 5:28 +         nop;                             // scope 0 at $DIR/simple.rs:5:9: 5:16 +         _0 = [const 0_u8; 1024];         // scope 0 at $DIR/simple.rs:5:19: 5:28 </del> <ins> StorageLive(_2);                 // scope 0 at $DIR/simple.rs:5:9: 5:16 _2 = [const 0_u8; 1024];         // scope 0 at $DIR/simple.rs:5:19: 5:28 </ins> StorageLive(_3);                 // scope 1 at $DIR/simple.rs:6:5: 6:19 StorageLive(_4);                 // scope 1 at $DIR/simple.rs:6:5: 6:9 _4 = _1;                         // scope 1 at $DIR/simple.rs:6:5: 6:9 StorageLive(_5);                 // scope 1 at $DIR/simple.rs:6:10: 6:18 StorageLive(_6);                 // scope 1 at $DIR/simple.rs:6:10: 6:18 <del> -         _6 = &mut _2;                    // scope 1 at $DIR/simple.rs:6:10: 6:18 +         _6 = &mut _0;                    // scope 1 at $DIR/simple.rs:6:10: 6:18 </del> <ins> _6 = &mut _2;                    // scope 1 at $DIR/simple.rs:6:10: 6:18 </ins> _5 = &mut (*_6);                 // scope 1 at $DIR/simple.rs:6:10: 6:18 _3 = move _4(move _5) -> bb1;    // scope 1 at $DIR/simple.rs:6:5: 6:19 }

This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix


Question: return None; } <ins> // Handle the special case of -Wall. let wall = matches.opt_strs("W"); if wall.iter().any(|x| *x == "all") { print_wall_help(); return None; } </ins> // Don't handle -W help here, because we might first load plugins. let r = matches.opt_strs("Z"); if r.iter().any(|x| *x == "help") {

It would be nice if turned on all warnings, like how other compilers work.
At least with and , doesn't turn on all the warnings. I don't think turning all on the warnings is ever going to be useful because lots are going to be very domain specific (ones like already are). clang has a fairly useless to turn on all warnings, and to turn on all those included by , and also many more that are considered to be useful. Rust already has all the warnings viewed as useful and not too subjective on by default.
Oh, wow! Thanks for the detailed, thoughtful response. I'll definitely look into each of those options.
(FWIW the warnings are listed in and are almost all on by default)
I think there should be a catch-all lint group, that objectively enables all lints. Whenever programmers decide subjectively to allow lints in some instances, they may then do that on a case-by-case basis. And if an implemented lint simply does not make sense at all then it should be improved/removed. The existing lint group apparently does not include all built-in lint groups, contrary to the output of (): can this issue be reopened?
Reopening. However, I think we shouldn't have any sort of "enable all lints" option; rustc's lints are already all intended to have no or very few false positives (and as such are enabled by default where that makes sense). Could you talk about which specific lints are missing from the default warnings built-in list? I'm not personally aware of any. I'm also somewhat concerned that a or similar option would be confusing to some extent because "all" wouldn't include clippy lints (and probably can't, or at least not easily -- though I don't know the details here).
Issue triage: no longer prints , so that was fixed at some point. (it now prints ) I think it might be useful to have a message explaining why doesn't exist, point the user toward to see all available errors, and suggest adding a for a more thorough lint check. This would help beginners coming from other languages to 1) understand that most useful warnings are turned on by default, 2) tell the user that exists, and 3) show the user that warnings can be controlled from inside the source code, rather than the command line. If there's interest in doing this, I could make a PR.


Question: } } } <del> self.visit_ty(&typ); if let &Some(ref trait_ref) = trait_ref { self.process_path(trait_ref.ref_id, &trait_ref.path); } self.process_generic_params(generics, "", item.id); for impl_item in impl_items { let map = &self.tcx.hir(); self.process_impl_item(impl_item, map.local_def_id_from_node_id(item.id)); } </del> <ins> let map = &self.tcx.hir(); self.nest_tables(item.id, |v| { v.visit_ty(&typ); if let &Some(ref trait_ref) = trait_ref { v.process_path(trait_ref.ref_id, &trait_ref.path); } v.process_generic_params(generics, "", item.id); for impl_item in impl_items { v.process_impl_item(impl_item, map.local_def_id_from_node_id(item.id)); } }); </ins> } fn process_trait(

While compiling rayon:
cc
triage: P-high, assigning to . Removing nomination label.
The fact that this bug was unknown until now strikes me as a sign that we have never attempted to run on the rustc test suite (i.e. compiletest). is this true? Would it be worthwhile to attempt that experiment?
I'm not sure if this is the correct approach, but I just executed the with the following patch applied: and the test suite did crash/ended up all green. It might be a good idea to always run the tests along with save-analysis passed. Should that be optionally enabled? Should we run it, e.g. in the container?


Question: base_generics: &ty::Generics<'tcx>) -> ty::Generics<'tcx> { <del> ty_generics(ccx, FnSpace, generics, base_generics) </del> <ins> ty_generics(ccx, FnSpace, generics, base_generics, false) </ins> } fn ty_generic_predicates_for_fn<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>,

If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high


Question: let thread = thread_info::current_thread(); let name = thread.as_ref().and_then(|t| t.name()).unwrap_or("<unnamed>"); <del> let write = |err: &mut dyn crate::io::Write, backtrace: Option<BacktraceStyle>| { </del> <ins> let write = |err: &mut dyn crate::io::Write| { </ins> let _ = writeln!(err, "thread '{name}' panicked at {location}:n{msg}"); static FIRST_PANIC: AtomicBool = AtomicBool::new(true);

slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.


Question: <ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,


Question: <ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?


Question: <ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens:


Question: <ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with


Question: #![feature(staged_api)] #![doc(issue_tracker_base_url = "https://issue_url/")] <del> #![unstable(feature="test", issue = "32374")] </del> <ins> #![unstable(feature = "test", issue = "32374")] </ins> // @matches issue_32374/index.html '//*[@class="item-left unstable deprecated module-item"]/span[@class="stab deprecated"]'  //      'Deprecated'


Question: #![feature(staged_api)] #![doc(issue_tracker_base_url = "https://issue_url/")] <del> #![unstable(feature="test", issue = "32374")] </del> <ins> #![unstable(feature = "test", issue = "32374")] </ins> // @matches issue_32374/index.html '//*[@class="item-left unstable deprecated module-item"]/span[@class="stab deprecated"]'  //      'Deprecated'


Question: <ins> error[E0382]: use of moved value: `bar` --> $DIR/moved-value-on-as-ref-arg.rs:27:16 | LL |     let bar = Bar; |         --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait LL |     foo(bar); |         --- value moved here LL |     let _baa = bar; |                ^^^ value used here after move | help: borrow the value to avoid moving it | LL |     foo(&bar); |         + error[E0382]: use of moved value: `bar` --> $DIR/moved-value-on-as-ref-arg.rs:30:16 | LL |     let mut bar = Bar; |         ------- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait LL |     qux(bar); |         --- value moved here LL |     let _baa = bar; |                ^^^ value used here after move | note: if `Bar` implemented `Clone`, you could clone the value --> $DIR/moved-value-on-as-ref-arg.rs:5:1 | LL | struct Bar; | ^^^^^^^^^^ consider implementing `Clone` for this type ... LL |     qux(bar); |         --- you could clone this value help: borrow the value to avoid moving it | LL |     qux(&mut bar); |         ++++ error[E0382]: use of moved value: `bar` --> $DIR/moved-value-on-as-ref-arg.rs:33:16 | LL |     let bar = Bar; |         --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait LL |     bat(bar); |         --- value moved here LL |     let _baa = bar; |                ^^^ value used here after move | help: borrow the value to avoid moving it | LL |     bat(&bar); |         + error[E0382]: use of moved value: `bar` --> $DIR/moved-value-on-as-ref-arg.rs:36:16 | LL |     let mut bar = Bar; |         ------- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait LL |     baz(bar); |         --- value moved here LL |     let _baa = bar; |                ^^^ value used here after move | note: if `Bar` implemented `Clone`, you could clone the value --> $DIR/moved-value-on-as-ref-arg.rs:5:1 | LL | struct Bar; | ^^^^^^^^^^ consider implementing `Clone` for this type ... LL |     baz(bar); |         --- you could clone this value help: borrow the value to avoid moving it | LL |     baz(&mut bar); |         ++++ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0382`. </ins>

... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :


Question: <ins> // compile-flags: -Z unstable-options --document-hidden-items // test for trait methods with `doc(hidden)` with `--document-hidden-items` passed. #![crate_name = "foo"] // @has foo/trait.Trait.html // @has - '//*[@id="associatedtype.Foo"]' 'type Foo' // @has - '//*[@id="associatedtype.Bar"]' 'type Bar' // @has - '//*[@id="tymethod.f"]' 'fn f()' // @has - '//*[@id="tymethod.g"]' 'fn g()' pub trait Trait { #[doc(hidden)] type Foo; type Bar; #[doc(hidden)] fn f(); fn g(); } // @has foo/struct.S.html // @has - '//*[@id="associatedtype.Foo"]' 'type Foo' // @has - '//*[@id="associatedtype.Bar"]' 'type Bar' // @has - '//*[@id="method.f"]' 'fn f()' // @has - '//*[@id="method.g"]' 'fn g()' pub struct S; impl Trait for S { type Foo = (); type Bar = (); fn f() {} fn g() {} } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Rustdoc does not show in the documentation for . Instead, this happened: ! Since is properly hidden in the documentation for , the link for is broken. : Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: when generating trait impls and is not passed, skip all methods where the method in the original trait was hidden. See for a similar change - the relevant code is in .
claim


Question: token::EQ => { // x = foo::bar self.bump(); <ins> let path_lo = self.span.lo; </ins> path = ~[self.parse_ident()]; while self.token == token::MOD_SEP { self.bump();

For 'use' items of the form . [I don't see how to assign this to myself, but I have a patch which I will make into a PR soon]


Question:
"

" + ret_others[0] + ret_in_args[0] + ret_returned[0] + "
";  var search = getSearchElement();  search.innerHTML = output; showSearchResults(search); var tds = search.getElementsByTagName("td");

Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?


Question: use std::rc::Rc; use std::{i8, i16, i32, i64}; use syntax::abi::{X86, X86_64, Arm, Mips, Mipsel, Rust, RustCall}; <del> use syntax::abi::{RustIntrinsic, Abi}; </del> <ins> use syntax::abi::{RustIntrinsic, Abi, OsWindows}; </ins> use syntax::ast_util::{local_def, is_local}; use syntax::attr::AttrMetaMethods; use syntax::attr;

This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016


Question: <ins> //! Regression test for <https://github.com/rust-lang/rust/issues/100531> #![feature(no_core)] #![no_core] #![crate_name = "export_extern_crate_as_self"] // ignore-tidy-linelength // @is export_extern_crate_as_self.json "$.index[*][?(@.kind=='module')].name" "export_extern_crate_as_self" pub extern crate self as export_extern_crate_as_self; // Must be the same name as the crate already has </ins>

Found via and seems like a different issue than with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly +E-needs-mcve
MCVE: ` modify labels: -E-needs-mcve


Question: <ins> An inherent `impl` was written on a dyn auto trait. Erroneous code example: ```compile_fail,E0785 #![feature(auto_traits)] auto trait AutoTrait {} impl dyn AutoTrait {} ``` Dyn objects allow any number of auto traits, plus at most one non-auto trait. The non-auto trait becomes the "principal trait". When checking if an impl on a dyn trait is coherent, the principal trait is normally the only one considered. Since the erroneous code has no principal trait, it cannot be implemented at all. Working example: ``` #![feature(auto_traits)] trait PrincipalTrait {} auto trait AutoTrait {} impl dyn PrincipalTrait + AutoTrait + Send {} ``` </ins>

Given the following code (): The current output is: This is rather confusing. It's not immediately clear what the difference between and this working code is (): Since is accepted, the user might be confused why would be considered a nominal type when isn't. The real reason why is an error is because it is an block for . Ideally the output should look like:
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (): Note that this still happens with auto traits in the same crate, but in this case wouldn't be applicable (): The diagnostic is still confusing in this case and could be rewritten to explicitly point out that is not allowed. modify labels: +D-confusing +F-auto_traits


Question: match context { PlaceContext::MutatingUse(_) => ty::Invariant, <del> PlaceContext::NonUse(StorageDead | StorageLive | PlaceMention | VarDebugInfo) => { ty::Invariant } </del> <ins> PlaceContext::NonUse(StorageDead | StorageLive | VarDebugInfo) => ty::Invariant, </ins> PlaceContext::NonMutatingUse( <del> Inspect | Copy | Move | SharedBorrow | ShallowBorrow | UniqueBorrow | AddressOf | Projection, </del> <ins> Inspect | Copy | Move | PlaceMention | SharedBorrow | ShallowBorrow | UniqueBorrow | AddressOf | Projection, </ins> ) => ty::Covariant, PlaceContext::NonUse(AscribeUserTy) => ty::Covariant, }

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct X([u8]); pub static Y: &'static X = { const Y: &'static [u8] = b""; &X(*Y) //~^ ERROR cannot move out //~^^ ERROR cannot move a //~^^^ ERROR cannot move a }; fn main() {} </ins>

This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct X([u8]); pub static Y: &'static X = { const Y: &'static [u8] = b""; &X(*Y) //~^ ERROR cannot move out //~^^ ERROR cannot move a //~^^^ ERROR cannot move a }; fn main() {} </ins>

Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct X([u8]); pub static Y: &'static X = { const Y: &'static [u8] = b""; &X(*Y) //~^ ERROR cannot move out //~^^ ERROR cannot move a //~^^^ ERROR cannot move a }; fn main() {} </ins>

Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details


Question: // take the "else" branch if self.option_loud_drop(6).is_some() // 2 && self.option_loud_drop(5).is_some() // 1 <del> && let None = self.option_loud_drop(7) { // 3 </del> <ins> && let None = self.option_loud_drop(8) { // 4 </ins> unreachable!(); } else { <del> self.print(8); // 4 </del> <ins> self.print(7); // 3 </ins> } // let exprs interspersed

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


Question: // take the "else" branch if self.option_loud_drop(6).is_some() // 2 && self.option_loud_drop(5).is_some() // 1 <del> && let None = self.option_loud_drop(7) { // 3 </del> <ins> && let None = self.option_loud_drop(8) { // 4 </ins> unreachable!(); } else { <del> self.print(8); // 4 </del> <ins> self.print(7); // 3 </ins> } // let exprs interspersed

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


Question: <ins> // This code (probably) _should_ compile, but it currently does not because we // are not smart enough about implied bounds. use std::io; fn real_dispatch<T, F>(f: F) -> Result<(), io::Error> //~^ NOTE required by a bound in this where F: FnOnce(&mut UIView<T>) -> Result<(), io::Error> + Send + 'static, //~^ NOTE required by this bound in `real_dispatch` //~| NOTE required by a bound in `real_dispatch` { todo!() } #[derive(Debug)] struct UIView<'a, T: 'a> { _phantom: std::marker::PhantomData<&'a mut T>, } trait Handle<'a, T: 'a, V, R> { fn dispatch<F>(&self, f: F) -> Result<(), io::Error> where F: FnOnce(&mut V) -> R + Send + 'static; } #[derive(Debug, Clone)] struct TUIHandle<T> { _phantom: std::marker::PhantomData<T>, } impl<'a, T: 'a> Handle<'a, T, UIView<'a, T>, Result<(), io::Error>> for TUIHandle<T> { fn dispatch<F>(&self, f: F) -> Result<(), io::Error> where F: FnOnce(&mut UIView<'a, T>) -> Result<(), io::Error> + Send + 'static, { real_dispatch(f) //~^ ERROR expected a `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` //~| NOTE expected an `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` //~| NOTE expected a closure with arguments //~| NOTE required by a bound introduced by this call } } fn main() {} </ins>

Sorry, this is not necessarily the smallest possible example. Please let me know if this is unhelpful and I'll come up with something more concise. Given the following code: The output in current stable (1.63.0) is: (Please note the "expected closure with ... found closure with ..." hint.) From 1.64 onwards, the expected/found hint is omitted: To me the 1.63 behaviour is preferable to that from 1.64+ as it can often be non-obvious where the differences lie.
searched nightlies: from nightly-2022-06-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Looks like it was caused by , which is pretty big diagnostics PR in that rollup. cc
Of course I caused it.
label -E-needs-bisection
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: /// Parse a `mod <foo> { ... }` or `mod <foo>;` item fn parse_item_mod(&mut self, outer_attrs: &[Attribute]) -> PResult<'a, ItemInfo> { <del> let outer_attrs = ::config::StripUnconfigured { config: &self.cfg, sess: self.sess, should_test: false, // irrelevant features: None, // don't perform gated feature checking }.process_cfg_attrs(outer_attrs.to_owned()); </del> <ins> let (in_cfg, outer_attrs) = { let mut strip_unconfigured = ::config::StripUnconfigured { config: &self.cfg, sess: self.sess, should_test: false, // irrelevant features: None, // don't perform gated feature checking }; let outer_attrs = strip_unconfigured.process_cfg_attrs(outer_attrs.to_owned()); (strip_unconfigured.in_cfg(&outer_attrs), outer_attrs) }; </ins> let id_span = self.span; let id = self.parse_ident()?; if self.check(&token::Semi) { self.bump(); <del> // This mod is in an external file. Let's go get it! let (m, attrs) = self.eval_src_mod(id, &outer_attrs, id_span)?; Ok((id, m, Some(attrs))) </del> <ins> if in_cfg { // This mod is in an external file. Let's go get it! let (m, attrs) = self.eval_src_mod(id, &outer_attrs, id_span)?; Ok((id, m, Some(attrs))) } else { let placeholder = ast::Mod { inner: syntax_pos::DUMMY_SP, items: Vec::new() }; Ok((id, ItemKind::Mod(placeholder), None)) } </ins> } else { let directory = self.directory.clone(); self.push_directory(id, &outer_attrs);

This fails on stable because rust still parses the unstable module: It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:
Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the syntax but not what it means.
That's actually what I'm doing in my project (still the same problem). That is, I have the following in my : And a module,
Modules are parsed before 's are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?
Dupe of . cc ( expert!)
Though this'll be fixed by the above PR, the workaround for current stable is