Question: <del> Subproject commit 50ef22af522f2545295090cc1ad3e4bd4aa8632c </del> <ins> Subproject commit b8f617897a66953b9026c02f7a8f93a2e9611f63 </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!


Question: "regex-syntax", "semver", "serde", <del> "smallvec 0.6.10", </del> <ins> "smallvec 1.0.0", </ins> "toml", "unicode-normalization", "url 2.1.0",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing nomination label.


Question: panic!("dist: Error calling canonicalize path `{}`: {}", llvm_dylib_path.display(), e); }); <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } } <ins> /// Maybe add libLLVM.so to the target lib-dir for linking. pub fn maybe_install_llvm_target(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join("lib/rustlib").join(&*target).join("lib"); maybe_install_llvm(builder, target, &dst_libdir); } /// Maybe add libLLVM.so to the runtime lib-dir for rustc itself. pub fn maybe_install_llvm_runtime(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); maybe_install_llvm(builder, target, &dst_libdir); } </ins> #[derive(Clone, Debug, Eq, Hash, PartialEq)] pub struct LlvmTools { pub target: Interned<String>,

Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.


Question: panic!("dist: Error calling canonicalize path `{}`: {}", llvm_dylib_path.display(), e); }); <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } } <ins> /// Maybe add libLLVM.so to the target lib-dir for linking. pub fn maybe_install_llvm_target(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join("lib/rustlib").join(&*target).join("lib"); maybe_install_llvm(builder, target, &dst_libdir); } /// Maybe add libLLVM.so to the runtime lib-dir for rustc itself. pub fn maybe_install_llvm_runtime(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); maybe_install_llvm(builder, target, &dst_libdir); } </ins> #[derive(Clone, Debug, Eq, Hash, PartialEq)] pub struct LlvmTools { pub target: Interned<String>,

Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?


Question: h2, h3, h4 { border-bottom: 1px solid; } <del> .impl, .method, .type:not(.container-rustdoc), .associatedconstant, .associatedtype { </del> <ins> .impl, .impl-items .method, .impl-items .type, .impl-items .associatedconstant, .impl-items .associatedtype { </ins> flex-basis: 100%; font-weight: 600; margin-top: 16px;

It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 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: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:16:16 | LL |     take_range(std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:21:16 | LL |     take_range(::std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&::std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:26:16 | LL |     take_range(std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:31:16 | LL |     take_range(::std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&::std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:36:16 | LL |     take_range(std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:41:16 | LL |     take_range(::std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&::std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:46:16 | LL |     take_range(std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:51:16 | LL |     take_range(::std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&::std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:56:16 | LL |     take_range(std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:61:16 | LL |     take_range(::std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&::std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:66:16 | LL |     take_range(std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:71:16 | LL |     take_range(::std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&::std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 12 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

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


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:16:16 | LL |     take_range(std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:21:16 | LL |     take_range(::std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&::std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:26:16 | LL |     take_range(std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:31:16 | LL |     take_range(::std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&::std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:36:16 | LL |     take_range(std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:41:16 | LL |     take_range(::std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&::std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:46:16 | LL |     take_range(std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:51:16 | LL |     take_range(::std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&::std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:56:16 | LL |     take_range(std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:61:16 | LL |     take_range(::std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&::std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:66:16 | LL |     take_range(std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:71:16 | LL |     take_range(::std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&::std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 12 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

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


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:16:16 | LL |     take_range(std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:21:16 | LL |     take_range(::std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&::std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:26:16 | LL |     take_range(std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:31:16 | LL |     take_range(::std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&::std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:36:16 | LL |     take_range(std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:41:16 | LL |     take_range(::std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&::std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:46:16 | LL |     take_range(std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:51:16 | LL |     take_range(::std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&::std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:56:16 | LL |     take_range(std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:61:16 | LL |     take_range(::std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&::std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:66:16 | LL |     take_range(std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:71:16 | LL |     take_range(::std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&::std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 12 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

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


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:16:16 | LL |     take_range(std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:21:16 | LL |     take_range(::std::ops::Range { start: 0, end: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&::std::ops::Range { start: 0, end: 1 }` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:26:16 | LL |     take_range(std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:31:16 | LL |     take_range(::std::ops::RangeFrom { start: 1 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&::std::ops::RangeFrom { start: 1 }` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:36:16 | LL |     take_range(std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:41:16 | LL |     take_range(::std::ops::RangeFull {}); |                ^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&::std::ops::RangeFull {}` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:46:16 | LL |     take_range(std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:51:16 | LL |     take_range(::std::ops::RangeInclusive::new(0, 1)); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&::std::ops::RangeInclusive::new(0, 1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:56:16 | LL |     take_range(std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:61:16 | LL |     take_range(::std::ops::RangeTo { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&::std::ops::RangeTo { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:66:16 | LL |     take_range(std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-literals.rs:71:16 | LL |     take_range(::std::ops::RangeToInclusive { end: 5 }); |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&::std::ops::RangeToInclusive { end: 5 }` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 12 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

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


Question: // integer literal, push to vector expression ast::LitIntUnsuffixed(v) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large integer literal in bytes!"); err = true; </ins> } else if v < 0 { <del> cx.span_err(expr.span, "negative integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "negative integer literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.


Question: // integer literal, push to vector expression ast::LitIntUnsuffixed(v) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large integer literal in bytes!"); err = true; </ins> } else if v < 0 { <del> cx.span_err(expr.span, "negative integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "negative integer literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

(I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

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


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":


Question: _ => self.is_free(), } } <ins> pub fn is_var(self) -> bool { matches!(self.kind(), ty::ReVar(_)) } </ins> } /// Type utilities

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: <ins> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

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> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

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> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

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> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

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: fn expect_aborted(status: ExitStatus) { dbg!(status); let signal = status.signal().expect("expected child process to die of signal"); <ins> #[cfg(not(target_os = "android"))] </ins> assert!(signal == libc::SIGABRT || signal == libc::SIGILL || signal == libc::SIGTRAP); <ins> #[cfg(target_os = "android")] { // Android signals an abort() call with SIGSEGV at address 0xdeadbaad // See e.g. https://groups.google.com/g/android-ndk/c/laW1CJc7Icc assert!(signal == libc::SIGSEGV); // Additional checks performed: // 1. Find last tombstone (similar to coredump but in text format) from the //    same executable (path) as we are (must be because of usage of fork): //    This ensures that we look into the correct tombstone. // 2. Cause of crash is a SIGSEGV with address 0xdeadbaad. // 3. libc::abort call is in one of top two functions on callstack. // The last two steps distinguish between a normal SIGSEGV and one caused // by libc::abort. let this_exe = std::env::current_exe().unwrap().into_os_string().into_string().unwrap(); let exe_string = format!(">>> {this_exe} <<<"); let tombstone = (0..100) .map(|n| format!("/data/tombstones/tombstone_{n:02}")) .filter(|f| std::path::Path::new(&f).exists()) .map(|f| std::fs::read_to_string(&f).expect("Cannot read tombstone file")) .filter(|f| f.contains(&exe_string)) .last() .expect("no tombstone found"); println!("Content of tombstone:n{tombstone}"); assert!( tombstone.contains("signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad") ); let abort_on_top = tombstone .lines() .skip_while(|l| !l.contains("backtrace:")) .skip(1) .take_while(|l| l.starts_with("    #")) .take(2) .any(|f| f.contains("/system/lib/libc.so (abort")); assert!(abort_on_top); } </ins> } fn main() {

<!-- 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 am trying to fix it so that Rust's stdlib prevents unwinding, or allocating, in the child, after a fork on Unix (including in ). That is . (Allocation after fork of a multithreaded program is UB in several libcs.) I a new test case, Unfortunately this test fails, but just on Android: I have few good theories as to why. I wrote some speculations: I think this probably needs attention from an Android expert to try to repro and fix this issue. I suspect it's a problem with the library rather than the tests. The worst case is that it might be a general UB bug in Android Rust programs using or . I'm filing this issue here to try to ask for help again, since writing in doesn't seem like a particularly good way of getting the attention of Android folks. If we can't get a resolution, reluctantly, I guess I will disable that test on Android so that my MR can go through. The current situation is quite a hazard (see eg "panic! in Command child forked from non-main thread results in exit status 0") I will try to explain what the test does and what the symptoms seem to mean: The test file has a custom global allocator, whose purpose is to spot allocations in the child after fork. That global allocator has an atomic variable which is supposed to contain either zero (initially, meaning it's not engaged yet) or the process's pid. Whenever an allocator method is called, we read the atomic and, if it is not zero, we check it against . If it doesn't match we <strike</strike. The test enters , and engages the stunt allocator, recording the program's pid. Each call to (which is called from and therefore from ) produces output from . We see only one of these, so this must be the first test, . The test uses to fork. In the child, it calls (my new function to disable panic unwinding). It then panics (using the provided closure). This ought to result in the program dying with (or maybe or ). The parent collects the child's exit status. For the first test case, we run .


Question: fn expect_aborted(status: ExitStatus) { dbg!(status); let signal = status.signal().expect("expected child process to die of signal"); <ins> #[cfg(not(target_os = "android"))] </ins> assert!(signal == libc::SIGABRT || signal == libc::SIGILL || signal == libc::SIGTRAP); <ins> #[cfg(target_os = "android")] { // Android signals an abort() call with SIGSEGV at address 0xdeadbaad // See e.g. https://groups.google.com/g/android-ndk/c/laW1CJc7Icc assert!(signal == libc::SIGSEGV); // Additional checks performed: // 1. Find last tombstone (similar to coredump but in text format) from the //    same executable (path) as we are (must be because of usage of fork): //    This ensures that we look into the correct tombstone. // 2. Cause of crash is a SIGSEGV with address 0xdeadbaad. // 3. libc::abort call is in one of top two functions on callstack. // The last two steps distinguish between a normal SIGSEGV and one caused // by libc::abort. let this_exe = std::env::current_exe().unwrap().into_os_string().into_string().unwrap(); let exe_string = format!(">>> {this_exe} <<<"); let tombstone = (0..100) .map(|n| format!("/data/tombstones/tombstone_{n:02}")) .filter(|f| std::path::Path::new(&f).exists()) .map(|f| std::fs::read_to_string(&f).expect("Cannot read tombstone file")) .filter(|f| f.contains(&exe_string)) .last() .expect("no tombstone found"); println!("Content of tombstone:n{tombstone}"); assert!( tombstone.contains("signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad") ); let abort_on_top = tombstone .lines() .skip_while(|l| !l.contains("backtrace:")) .skip(1) .take_while(|l| l.starts_with("    #")) .take(2) .any(|f| f.contains("/system/lib/libc.so (abort")); assert!(abort_on_top); } </ins> } fn main() {

This extracts the signal number from it and checks that it is as expected. On other systems this works. In the failing test, this test fails. The assertion on fails. Meaning, the child did die of a signal but the signal number wasn't the one expected. The previous debug print shows that the raw wait status (confusingly described by Rust stdlib as an "exit status") is <strike</strike. Usually, a bare number like that in a wait status is a signal number, and indeed that seems to be the case here since is . On Linux (and most Unices), is and 10 is . Ie, it seems that the child tried to allocate memory, despite my efforts to make sure that panicking does not involve allocation. Weirdly, a more-portable test case which uses and does not insist on specific signal numbers passes. It's definitely my stunt allocator which is tripping here, because when I changed it to use instead of , the failing test case signal number changed too.
modify labels +O-android +T-libs-impl
<strike provided an explanation here I still think there is a bug here but it is not Android-specific. I have a WIP branch to try to address it, so I think it's probably best if I close this issue and submit that as an MR when it's ready.</strike
My first guesses were right. In where I changed the stunt allocator to use , we see this:
I found a memory allocation with a patched Miri: With this code:
Apparently, the thread locals aren't working as expected. I think the child after fork is being treated as a new thread, and then the thread local storage has to be re-created. I think the surviving thread in the fork should inherit all the thread-locals from the forking thread in the parent.
But I just tested the code after , so there's no "new thread" or "parent" here...
Oh! Yes. You are right. Evidently the first use of this thread-local allocates. Presumably that would happen on a new thread as well as on the initial thread. Having panic rely on thread-locals, and thread-locals rely on the allocator, seems unfortunate. Having panic allocate is not good, especially when actually it's just trying to abort precisely to avoid this.


Question: fn expect_aborted(status: ExitStatus) { dbg!(status); let signal = status.signal().expect("expected child process to die of signal"); <ins> #[cfg(not(target_os = "android"))] </ins> assert!(signal == libc::SIGABRT || signal == libc::SIGILL || signal == libc::SIGTRAP); <ins> #[cfg(target_os = "android")] { // Android signals an abort() call with SIGSEGV at address 0xdeadbaad // See e.g. https://groups.google.com/g/android-ndk/c/laW1CJc7Icc assert!(signal == libc::SIGSEGV); // Additional checks performed: // 1. Find last tombstone (similar to coredump but in text format) from the //    same executable (path) as we are (must be because of usage of fork): //    This ensures that we look into the correct tombstone. // 2. Cause of crash is a SIGSEGV with address 0xdeadbaad. // 3. libc::abort call is in one of top two functions on callstack. // The last two steps distinguish between a normal SIGSEGV and one caused // by libc::abort. let this_exe = std::env::current_exe().unwrap().into_os_string().into_string().unwrap(); let exe_string = format!(">>> {this_exe} <<<"); let tombstone = (0..100) .map(|n| format!("/data/tombstones/tombstone_{n:02}")) .filter(|f| std::path::Path::new(&f).exists()) .map(|f| std::fs::read_to_string(&f).expect("Cannot read tombstone file")) .filter(|f| f.contains(&exe_string)) .last() .expect("no tombstone found"); println!("Content of tombstone:n{tombstone}"); assert!( tombstone.contains("signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad") ); let abort_on_top = tombstone .lines() .skip_while(|l| !l.contains("backtrace:")) .skip(1) .take_while(|l| l.starts_with("    #")) .take(2) .any(|f| f.contains("/system/lib/libc.so (abort")); assert!(abort_on_top); } </ins> } fn main() {

Since is stored in which is not a thread-local, maybe the program could abort before using any thread-local.
It can't do that and also print the payload, because printing the payload might itself panic, and the recursive panic needs to be detected.
Maybe instead there should be a which can return None to mean "this thread-local variable has not been initialised".
I think it might be possible to use a to avoid the allocation.
Do thread-local always avoid the allocation? I think they fall back to regular thread-locals on platforms where avoiding allocations is not (easily) possible.
The version of looks basically same as the non- version when using , which will likely allocate here: Maybe the panic count could be stored directly in rather than on the heap. But is itself safe after ? If it tries to hold a lock or something it's possible to deadlock.
Should this only occur on Android? It happened on QNX as well (not yet upstreamed, work in progress so I don't trust it yet), but I can also reproduce it on with a simple patch (disables thread local storage): Would this be a target spec where we would expect to succeed?
Interesting. To be honest, I'm not sure. I do know that modern libc doctrine is that allocation after fork is UB. The test case is checking that we can safely panic after fork, and abort, without UB. This ought to work due to . I think that every failure of this test case is a real bug. Solving those bugs is not so easy because the machinery inside panic uses thread-local state which apparently is really super hard to make work without allocating or taking locks.
Yes, allocating memory is UB, same as working with mutexes. In case our setups are okay (i.e. having and using fork etc.), I also see this is a bug. Maybe we don't need to fix the issue with the thread-local state (if at all possible): calls to get the number recursive panics and if we . : determines using --works determines number recursive panics using TLS --allocates after --UB first: If it is true, it will always call -- the process will be killed very very soon by the OS In case of a recursion, a hardcoded-string is printed; otherwise additionally Do we really need to correctly determine a recursion, or can we allow "false positives"?


Question: fn expect_aborted(status: ExitStatus) { dbg!(status); let signal = status.signal().expect("expected child process to die of signal"); <ins> #[cfg(not(target_os = "android"))] </ins> assert!(signal == libc::SIGABRT || signal == libc::SIGILL || signal == libc::SIGTRAP); <ins> #[cfg(target_os = "android")] { // Android signals an abort() call with SIGSEGV at address 0xdeadbaad // See e.g. https://groups.google.com/g/android-ndk/c/laW1CJc7Icc assert!(signal == libc::SIGSEGV); // Additional checks performed: // 1. Find last tombstone (similar to coredump but in text format) from the //    same executable (path) as we are (must be because of usage of fork): //    This ensures that we look into the correct tombstone. // 2. Cause of crash is a SIGSEGV with address 0xdeadbaad. // 3. libc::abort call is in one of top two functions on callstack. // The last two steps distinguish between a normal SIGSEGV and one caused // by libc::abort. let this_exe = std::env::current_exe().unwrap().into_os_string().into_string().unwrap(); let exe_string = format!(">>> {this_exe} <<<"); let tombstone = (0..100) .map(|n| format!("/data/tombstones/tombstone_{n:02}")) .filter(|f| std::path::Path::new(&f).exists()) .map(|f| std::fs::read_to_string(&f).expect("Cannot read tombstone file")) .filter(|f| f.contains(&exe_string)) .last() .expect("no tombstone found"); println!("Content of tombstone:n{tombstone}"); assert!( tombstone.contains("signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad") ); let abort_on_top = tombstone .lines() .skip_while(|l| !l.contains("backtrace:")) .skip(1) .take_while(|l| l.starts_with("    #")) .take(2) .any(|f| f.contains("/system/lib/libc.so (abort")); assert!(abort_on_top); } </ins> } fn main() {

Instead of having UB, I think it would be fine to only check the number of overall current panics calls (as stored in ignoring ). If it is higher than 2, assume we have a recursion (results in false positives in case two or more threads panic at the same time). ==In case we have two panics going on in parallel by two threads there is the chance that we don't output , but it prevents UB. Also, when one thread calls it will often happen that the second thread will be killed soon and outputs nothing at all. In other cases (only one thread panics), there should be no difference. A change could look like that (high probability I've missed something!): This change passes all tests of for targets and QNX on AArch64.
Would you please try to test the fix above to check if it solves the issue on Android as well?
On most Unix it's UB to touch TLS after fork. Even if we have static TLS, accessing it might cause [^1] to be be called, and that function has paths where it allocates memory, takes locks, etc. That is, this is probably not a specific issue with QNX/Android. [^1]: At least on ELF, although I believe this is broadly true for Mach-O as well.


Question: use crate::TargetSelection; use crate::{t, VERSION}; <ins> use std::env::consts::EXE_SUFFIX; </ins> use std::fmt::Write as _; <del> use std::path::{Path, PathBuf}; </del> <ins> use std::fs::File; use std::path::{Path, PathBuf, MAIN_SEPARATOR}; </ins> use std::process::Command; use std::str::FromStr; use std::{

I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim


Question: <ins> // Regression test for #89469, where an extra non_snake_case warning was // reported for a shorthand field binding. // check-pass #![deny(non_snake_case)] #[allow(non_snake_case)] struct Entry { A: u16, a: u16 } fn foo() -> Entry {todo!()} pub fn f() { let Entry { A, a } = foo(); let _ = (A, a); } fn main() {} </ins>

Here's a minimized version of the code I'm working with: Compiling this on stable or nightly gives a warning on the indicated line, despite the attribute on . A similar issue was reported before in , and addressed in a follow-up PR , but it seems to be cropping up again here, maybe because a non-ASCII field name is involved. It was agreed in that punning of non-snake-case fields in patterns should not produce an additional warning, so I think this is a bona fide bug. (Incidentally, on stable the same warning appears twice in the compiler output, but this duplication seems to be fixed on nightly.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's actually unrelated to the non-ASCII field names; reduced: claim
Thanks


Question: <ins> error[E0283]: type annotations needed --> $DIR/issue-80816.rs:49:38 | LL |     let guard: Guard<Arc<usize>> = s.load(); |                                      ^^^^ | note: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found --> $DIR/issue-80816.rs:35:1 | LL | impl<T> Access<T> for ArcSwapAny<T> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | impl<T> Access<T> for ArcSwapAny<Arc<T>> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` --> $DIR/issue-80816.rs:31:45 | LL | impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { |                                             ^^^^^^^^^     ^ help: try using a fully qualified path to specify the expected types | LL |     let guard: Guard<Arc<usize>> = <Arc<ArcSwapAny<Arc<usize>>> as Access<T>>::load(&s); |                                    ++++++++++++++++++++++++++++++++++++++++++++++++++ ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>

A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test


Question: pub use self::stdio::set_output_capture; #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{stderr, stdin, stdout, Stderr, Stdin, Stdout}; <ins> #[unstable(feature = "stdio_locked", issue = "none")] pub use self::stdio::{stderr_locked, stdin_locked, stdout_locked}; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{StderrLock, StdinLock, StdoutLock}; #[unstable(feature = "print_internals", issue = "none")]

Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .


Question: pub use self::stdio::set_output_capture; #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{stderr, stdin, stdout, Stderr, Stdin, Stdout}; <ins> #[unstable(feature = "stdio_locked", issue = "none")] pub use self::stdio::{stderr_locked, stdin_locked, stdout_locked}; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{StderrLock, StdinLock, StdoutLock}; #[unstable(feature = "print_internals", issue = "none")]

is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:


Question: } } } <del> hir::ItemKind::Macro(ref macro_def) => { self.update_reachability_from_macro(item.def_id, macro_def); } </del> // Visit everything, but foreign items have their own levels. hir::ItemKind::ForeignMod { items, .. } => { for foreign_item in items {

EDIT (ehuss) Reproduction: Clone <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.


Question:
}).peekable(); if let doctree::Plain = s.struct_type { if fields.peek().is_some() {  write!(w, "
Fields
")?;   write!(w, "
 Fields
")?;  for (field, ty) in fields { let id = derive_id(format!("{}.{}", ItemType::StructField,

A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.


Question: <ins> // Regression test for #84632: Recursion limit is ignored // for builtin macros that eagerly expands. #![recursion_limit = "15"] macro_rules! a { () => (""); (A) => (concat!("", a!())); (A, $($A:ident),*) => (concat!("", a!($($A),*))) //~^ ERROR recursion limit reached //~| HELP consider adding } fn main() { a!(A, A, A, A, A); a!(A, A, A, A, A, A, A, A, A, A, A); } </ins>

I tried this code: I expected to see this happen: An error message about exceeding some recursion limit Instead, this happened: Tested on stable 1.51.0 + <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that the crash also occurs without . Based on testing with Godbolt, this doesn't seem to be a regression, or at least not a recent one.
Assigning as part of the prioritization working group discussion and removing . modify labels -I-prioritize +P-medium
Issue might be in this line: Calls , which then calls : And sets to , which would result in stack overflow because the recursion limit is never reached.
claim
Bug is confusing to track down, so I am no longer working on this. For people who are interested, here is the log when the loop is encountered: release-assignment
The issue is part of a bigger problem, that seems to ignore the recursion limit. This snippet below compiles successfully instead of reporting an error:
Seems to be a regression between and by testing on Godbolt. I suspect from caused the regression, but I'm not sure. label regression-untriaged


Question: if let hir::Node::Pat(parent_pat) = cx.tcx.hir().get(cx.tcx.hir().get_parent_node(hid)) { if let PatKind::Struct(_, field_pats, _) = &parent_pat.kind { <del> for field in field_pats.iter() { if field.ident != ident { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); } </del> <ins> if field_pats .iter() .any(|field| !field.is_shorthand && field.pat.hir_id == p.hir_id) { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); </ins> } return; }


Question: assert!(prev_predicates.is_none()); } <del> fn ty_generics_for_type_or_impl<'a, 'tcx>(ccx: &CrateCtxt<'a, 'tcx>, generics: &hir::Generics) -> ty::Generics<'tcx> { ty_generics(ccx, TypeSpace, generics, &ty::Generics::empty()) </del> <ins> fn ty_generics_for_type<'a, 'tcx>(ccx: &CrateCtxt<'a, 'tcx>, generics: &hir::Generics) -> ty::Generics<'tcx> { ty_generics(ccx, TypeSpace, generics, &ty::Generics::empty(), true) } fn ty_generics_for_impl<'a, 'tcx>(ccx: &CrateCtxt<'a, 'tcx>, generics: &hir::Generics) -> ty::Generics<'tcx> { ty_generics(ccx, TypeSpace, generics, &ty::Generics::empty(), false) </ins> } fn ty_generic_predicates_for_type_or_impl<'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: <ins> // no-system-llvm // compile-flags: -O -C overflow-checks=on #![crate_type = "lib"] pub struct S1<'a> { data: &'a [u8], position: usize, } // CHECK-LABEL: @slice_no_index_order #[no_mangle] pub fn slice_no_index_order<'a>(s: &'a mut S1, n: usize) -> &'a [u8] { // CHECK-NOT: slice_index_order_fail let d = &s.data[s.position..s.position+n]; s.position += n; return d; } // CHECK-LABEL: @test_check #[no_mangle] pub fn test_check<'a>(s: &'a mut S1, x: usize, y: usize) -> &'a [u8] { // CHECK: slice_index_order_fail &s.data[x..y] } </ins>

Godbolt: Basically the issue is that you compute , check that it doesn't overflow, and then you verify that is greater than , which it of course always is, since you checked for an overflow! This is probably an LLVM optimization bug, but I'm starting here :-) Command line arguments: Source: ASM:
Slightly reduced testcase: LLVM does not realize that and are the same here.
Ok, looks like the thing to do is file an LLVM bug -- do you know off hand if they're ok with Rust reproducers, or do they prefer C ones?
Ok, ended up converting to C because that seemed easy:
Submitted additionally for the IR pattern above (which is an issue separate from the missing combining). Just verified that fixing this does indeed eliminate the check in this example.
am I correct in reading that this has been waiting on a review of the LLVM patch?
Needs a rebase. More generally though, I think this is fighting a losing battle. and are not considered canonical IR for a reason: They optimize badly in the middle end. I think we'd be better off with generating the canonical variants instead (which are and ). LLVM will still form during CGP, but this should optimize better in the middle end (including avoiding the issue here). As we already have a good benchmark for the overhead of overflow checks in , I think it might be worth trying to rerun that without using the unsigned overflow intrinsics.
From the :
once this makes it's way into Rust's LLVM (is there a good way to track this?) I'll verify that the assembly in this bug was improved, and if so I'll rebase the rustc patch and we can get some new numbers!
Ok, confirmed that the recent LLVM10 update removes this branch: Shall this be closed?
Actually, that was probably premature. We should add a codegen test.
is there a good example of what a test looks like? I can spin one up pretty easily if someone can point me at how to add one.
Codegen tests are located in . One test that is thematically related: . They use . Codegen tests can be run with:
Thanks much, that's exactly what I needed! PR is up now.


Question: expr_span, scope, result, <del> value.ty, </del> <ins> expr.ty, </ins> ); }

mentioned a leak coming from but not , I think I tracked this down to the use of in when given a comma-separated list. I've made that demonstrates it with , if it gets much simpler than this then the leak doesn't occur when built with --release. I'm testing on rustc 1.37.0-nightly ( 2019-06-30) nightly-x8664-pc-windows-msvc, targeting x8664-pc-windows-msvc.
Valgrind Memcheck also reports heap in use at exit on a Linux VM with the test linked above.
Thanks a lot for creating a reduced test case and creating this issue here. I stumbled over the original issue when carg-fuzz reported a memory leak in this code This PR appears to fix the issue This was also with rustc 1.37.0-nightly on Linux. I can check if I can repro with the fuzz test case on other platforms.
Looks like the early return doesn't interact well with box syntax's preallocation. MIR generation issue? cc
should be here: Now that can only schedule drops for locals, we should get the type from to avoid this sort of problem in the future.
Confirmed with my fuzzing test case that the problem is fixed in the latest rust nightly. Thanks for fixing it so quickly.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::Url; /// /// let raw = "https://username@example.com:8080/foo/bar?baz=qux#quz";

The common fix for , , and is to rewrite the module based on the spec at and the tests at (Note: the tests assume the API, designed for JavaScript in web browsers. We do not necessarily want the same API for Rust outside of testing code.)
I'm interested in this
I have a work-in-progress implementation. I’ll publish it later today so you can pick it up if you want.
Here it is: Note that I’m targeting Rust , the version used in Servo. (Though there is an upgrade being worked on.) IDNA and the actual URL parser are not there yet, but everything else (host/domain/ipv6, , percent encoding, test harness) is there. This should start being useful as soon as the URL parser is . The host parser returns an error on non-ASCII domains. This is good enough for now, IDNA support can be later. also made an in-progress implementation: It has some known bugs ( is incorrect with non-ASCII input, at least) but the parser code can probably be reused.
Also, be aware that the URL spec itself is still moving and has a number of open bugs:
I Punycode encoding and decoding (with tests) to but not Nameprep, which is the other big part of IDNA.
is now (IMHO) ready to replace . It is not "done" yet (some bugs remain, including in the spec!), but at this point it has more than feature-parity and is probably correct in more corner cases. Given the current tendency to move things out of , rust-url probably shouldn’t move in. It could be distributed with rustc like the rest of the modules moving out of extra, but this has the downside of tying rust-url upgrades to compiler upgrades, and only weak advantages IMO. So, whenever the Rust team decides it’s appropriate, I suggest removing and recommending rust-url as a replacement.
I would generally be in favor of a in the distribution for now. This would certainly not be a package in long-term, but for now putting everything in this repo is the ad-hoc solution we have until we get a real package manager.
In that case, I’d like to iterate a bit on rust-url (port rust-http and Servo to it, …) before it moves into the distribution. Also, rust-url depends on rust-encoding, which I guess would have to move as well.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::Url; /// /// let raw = "https://username@example.com:8080/foo/bar?baz=qux#quz";

I’d say rust-url is now in "beta" state. I have branches of rust-http and Servo using it: It builds with Cargo. It depends on rust-encoding (which also builds with Cargo), but for something non-essential that could be deactivated if avoiding the additional dependency helps. I’d like people to start using it and give feedback. I think the best way to do that is to get rid of the old liburl. I’ll go through the RFC process, but before that, what would you prefer? Replace liburl with snapshots[] of rust-url. You were in favor of this in February, but Cargo has reached alpha since then. Just remove liburl, and tell people to use rust-url through Cargo. Something else? [] In any case, I’d like to keep a separate rust-url repository that I can update in Servo independently of language upgrades.
+1 on removing liburl. Thanks
Perhaps we can deprecate all of liburl for one release cycle.
This seems like a great place to let cargo shine.
Deprecating sounds reasonable. That means emitting warnings by default, right?
awesome work! I agree with and that I think this is where cargo shines, and we can probably just remove liburl entirely without re-adding rust-url. We can also try to grow more official support for it in terms of documentation and automation (not present currently). We can mark liburl as with a message to use instead which should ferry everyone along quickly.


Question: exact_paths: Default::default(), modules: vec![om], is_importable_from_parent: true, <ins> inside_body: false, </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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.


Question: <ins> #![feature(unsize)] use std::marker::Unsize; use std::ops::Deref; trait Foo: Bar {} trait Bar {} impl<T> Bar for T where dyn Foo: Unsize<dyn Bar> {} impl Bar for () {} //~^ ERROR conflicting implementations of trait `Bar` for type `()` fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'', 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait -- label +F-Unsize +F-unsize
The bisection looks incorrect? is from 1.77, and this looks to be from 1.72 to me.
Too lazy to look at its PRs :
Due to . This assertion is correct, and we probably shouldn't drop candidates in intercrate mode, since this is incomplete. I would say this fix is low-pri because of the fact that is not expected to be referenced.


Question: // seemingly completely unrelated change. // Unfortunately, LLVM has no "disable" option for this, so we have to set // "enable" to 0 instead. // compile-flags:-g -Cllvm-args=-enable-tail-merge=0 // ignore-pretty as this critically relies on line numbers

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


Question: &self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

I was using std::io::copy from an SSD to memory using , which reported an eye-raising 30 MB/s. Wrapping it in a BufReader (either as the outer or middle layer) made no real difference. So I googled around a bit and found the recommended size was 64KB according to some random Microsoft article, so I decided to copy-paste the std::io::copy implementation and increase the buffer size. This got up to 600 MB/s at about 256KB which sounded a lot more it continued going upwards from there past the point of believability (unless the files were being pulled from RAM as a consequence of my repeated accesses). With a 10MB Vec, I got 228.36 GB/s . Unrealistic values aside, has anybody checked the buffer value to make sure there isn't some huge low-hanging fruit for std::io::copy speeds?
You mention windows. This may be platform-specific behavior. On unix systems I would fadvise on the input file for copying. Googling tells me that the windows equivalent is . Have you tried that?
After a coarse overview, my intuition is that there is some funny business going on with the length determined by and the subsequent calls on the , that could explain the unrealistic results.
It’s possible. The actual times did increase dramatically from the std::io::copy default though - my suspicion is that there is probably some caching to RAM going on or something as cold runs were generally slower than hot runs. This was for some work code that I’m no longer actively developing. I’ll leave this email marked as unread for awhile in case I have some spare time to write a benchmark. I don’t think the other flag that was mentioned is accessible with the default open file api, but in any case it at least appears there’s some low hanging fruit wrt to std::io::copy perf
I tried benchmarking on Windoze before and after changing to (instead of the original ) and the results were slightly worse (up to ~3%) with the modified setup, both on HDD and SSD. However, I'm not sure if my benchmarks were good enough - I was having a hard time tweaking them so that I could see any difference between results for different file sizes.


Question: &self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

FWIW, I'm providing the benchmark code below; it can easily be expanded to different file sizes:
4MB isn’t a whole lot. That’s well within the size of hard drive caches or possibly an OS memory-based cache. I was noticing the difference with files several gigabytes in size. As a sanity check, maybe look to see what the actual time is, not just the % difference between timings with different buffer sizes. The actual time may be wildly different than the actual steady state performance of the disk if it’s reading the data from a cache. It may also be possible at a low level to pass a flag to encourage the OS to disable or flush the cache, but I don’t know if there’s any way to instruct the hard drive to do the same.
I only pasted the benchmark for 4MB as a reference - I tested files from 4KB up to 16MB. I'm not an expert with low-level hard drive stuff, just hoping my attempt can help someone else.
Ideally you would test with a file approximately twice as big as you have RAM, so if you have 8GB of RAM you would want to test with a 16GB file.
extended open flags are accessible via FWIW lots of bennchmarks exist showing synchronous IO calls improve when matching IO operations to the underlying block size (e.g. 4MB for modern SSD's) across multiple OS's, so its very likely that there are improvements to gain here. However, 4MB is stack-breaking size by default, and heap allocations will destroy potential improvements (and further, if we're optimising, we probably want overlapped IO and a ring of buffers rather than just one buffer which will always leave one device idle).... so its complex;)
heap allocations will destroy potential improvements How come? would allocate once at the beginning. Heap memory isn't inherently slower and one memory allocation is basically free compared to the heavy IO that's happening afterwards.
But we also don't want to be allocating 4MB every time we do as someone might be doing a bunch of small copies.


Question: &self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

possible approaches: thread local buffers or a buffer pool stat the input before deciding on the buffer size (this is what gnu cp does I think) heap-allocate a bigger buffer after a few iterations of the copy loop with an on-stack buffer specialize copy operations from file to memory to directly into the already allocated target, thus skipping the need for a buffer
specialize copy operations from file to memory to directly into the already allocated target, thus skipping the need for a buffer I think some kind of specialization for sources would be ideal. Because in this case, should not buffer at all and simply use the reader's buffer. Effectively this also gives you a customizable buffer size by wrapping your in a with whatever size you want. As of today, if your source is then is always the wrong answer. I got a substantial performance improvement using a simple loop instead:
a single heap allocation is entirely reasonable for a single invocation of copy of a lot of data. For many copies of a small amount of data, one ends up with a lot of allocations again (consider for instance copying data out of a tar, where we have views on the data and there's no actual synchronous IO etc happening. I like some of the suggested possibilities with specialisation.
It's a nice general optimization, but not necesarily ideal if you use a as . Adding a on the reader size does let you control the buffer size but it still introduces an unnecessary memcopy compared to . Perhaps a writer-side optimization would be more flexible. Then you can specialize either for or
That sounds rather uncommon to me though. After all, is provided by the trait so it's always available. The only case I can see where you would invoke with a as destination is some generic interfaces that takes any . But IMO such interfaces are ill-designed, as they could simply implement instead and offer a much more flexible API.
yes, generic code taking a write was the concern. E.g. tar-rs has a tar archive which takes a and is fed with items. I'm not saying that creating an in-memory archive would be a good idea, just pointing out that these patterns do exist.
I had same kind of issue but with different library (). The copy rate was around 70 MB/s (inside single NVMe SSD). The problem was actually with running the debug version of my program.