jiebi/CodeConvo huggingface dataset:
Change:
// // Note: in fact we only permit builtin traits, not `Bar<'d>`, I // am looking forward to the future here. <del> if !data.has_escaping_bound_vars() { </del> <ins> if !data.has_escaping_bound_vars() && !region.has_escaping_bound_vars() { </ins> let implicit_bounds = object_region_bounds(self.infcx.tcx, data);

Discussion:
(continuation of as it looks like a compiler bug after all, important points repeated here) There appear to be an issue in handling traits that have a parent bound boxed through an await point: the following example fails to compile with for<'r'r : 'static (note: I'm using generators for simplicity of reproduction, see below for a futures-only example) However, when removing the bound on , it appears to compile correctly, even though the itself still has the bound. The error originated in code that looked like: The being here the trait that has the bound. This was tested with at commit and nightly 2018-08-14. I couldn't manage to get a generator-only version to fail: this compiles. This is potentially related to , as the same appears there?
Some work has started on ; the information there will likely be helpful to someone trying to fix this.
I think I've hit this with a generator-only code.
I'm marking this issue as blocking the async-await stabilization -- if nothing else, we need to investigate it and figure out what is going on.
I did some more digging into this problem. This code will actually ICE if using a version of rustc built with debug assertions. Moreover, the follow example code -- which doesn't use generators at all -- will ICE in the same way: the problem here ultimately has to do with the way that the WF code works. I left some , but the bottom line is something like this: The WF code presently descends through binders but (generally speaking) opts not to prove WF conditions that involve higher-ranked regions. The strategy was described as "lazy" in the relevant RFC, but with the new universes code we can generally try to pursue something better, so I hope to get rid of it sooner or later. Anyway the idea is that whenever a higher-region is "expanded" with a particular value, we'll prove the WF at that point. So in this particular case we wind up with a type -- for this type to be WF, the region bound must hold. We are producing this constraint. If debug assertions are enabled, we ICE out because the constraint isn't supposed to include higher-ranked regions (here, ). But without debug assertions, we fail to detect that, and then we just wind up failing to prove it.

It's kind of hard to stumble across this ICE normally, because defaults to since we see the bound declared on . However, with generators, it occurs more readily because when constructing the generator witness, we replace the with a bound region (we replace all the internal regions in this way). Pursuant with the existing lazy strategy, I think the right fix is just for the wf code to ignore the constraint -- and that is a small patch to do. I will probably open a PR around this shortly.
Great, thank you! I can confirm that on latest nightly the issue is no longer there :D
Change:
/// throughout `std::io` take and provide types which implement the `Read` /// trait. /// <ins> /// Please note that each call to `read` may involve a system call, and /// therefore, using something that implements [`BufRead`][bufread], such as /// [`BufReader`][bufreader], will be more efficient. /// /// [bufread]: trait.BufRead.html /// [bufreader]: struct.BufReader.html /// </ins> /// # Examples /// /// [`File`][file]s implement `Read`:

Discussion:
On my computer, this takes about 0.011s to run. If you comment out the line to create the BufReader, the code still compiles... but it takes roughly 0m0.209s to run. It seems like Rust should try to prevent people from shooting themselves in the foot, although I'm not exactly sure what could be done short of deprecating it.
Do you think it's a trap even with the BufReader? It's surprisingly good.
The performance with BufReader seems fine... the problem is really the performance without BufReader. Actually, hmm... maybe the implementation of bytes() for File should build a BufReader? That seems a little awkward, but I guess it's potentially workable.
I can see where several impls could be performance traps with this method. Since essentially reads one byte for each call to , it can interact poorly with any impl that isn't tolerant of small, extremely frequent reads--basically exactly what is meant to help with. The easiest fix would be to document this on the method to let users know they should use a buffer for some cases. But without any way to warn them directly, a lot of users could still be bitten in the butt by this. can inherently use , and then can override to return itself in instead of constructing a new . But this will be unnecessary for other impls that don't need buffering, like . Another solution could be to let be dynamically buffered or raw: Then the impl can return by default, or be overridden to return . The drawback here is that the enum would have to be matched on with each call to , which would be a bit of a performance hit, though likely not nearly as bad as the performance problem it fixes, and should be ironed out by branch prediction after a few iterations.
BytesInner sounds good, but I'm not sure if we can actually do it. The problem is that it's a hidden buffer that the user can't recover -- think of the case , after iterating only a few bytes, then stopping, the rest of the buffered data is unreachable. It's not just about , it's about non-buffered I/O in general. We need to make it clear to users that files and network streams opened are unbuffered by default. Stdin is buffered. But you have less overhead if you it for multiple operations or for access access to the buffer methods.

The best solution with the least commitment is to educate the user better about buffers and when to use them.
Filing as a doc bug. We talk about this in BufReader, but not Read. Seems bad.
Change:
<ins> #![crate_name = "user"] // aux-crate:rpitit=ret-pos-impl-trait-in-trait.rs // edition:2021 // Test that we can correctly render cross-crate RPITITs. // In particular, check that we don't render the internal associated type generated by // their desugaring. We count the number of associated items and ensure that it is exactly one. // This is more robust than checking for the absence of the associated type. // @has user/trait.Trait.html // @has - '//*[@id="method.create"]' 'fn create() -> impl Iterator<Item = u64>' // The class "method" is used for all three kinds of associated items at the time of writing. // @count - '//*[@id="main-content"]//section[@class="method"]' 1 pub use rpitit::Trait; // @has user/struct.Basic.html // @has - '//*[@id="method.create"]' 'fn create() -> impl Iterator<Item = u64>' // @count - '//*[@id="trait-implementations-list"]//*[@class="impl-items"]' 1 pub use rpitit::Basic; // @has user/struct.Intermediate.html // @has - '//*[@id="method.create"]' 'fn create() -> Range<u64>' // @count - '//*[@id="trait-implementations-list"]//*[@class="impl-items"]' 1 pub use rpitit::Intermediate; // @has user/struct.Advanced.html // @has - '//*[@id="method.create"]' 'fn create() -> impl Iterator<Item = u64>' // @count - '//*[@id="trait-implementations-list"]//*[@class="impl-items"]' 1 pub use rpitit::Advanced; // Regression test for issue #113929: // @has user/trait.Def.html // @has - '//*[@id="method.def"]' 'fn def<T>() -> impl Default' pub use rpitit::Def; </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
PassMode::Ignore(IgnoreMode::Zst) => { return local(OperandRef::new_zst(bx.cx(), arg.layout)); } <del> PassMode::Ignore(IgnoreMode::CVarArgs) => { let backend_type = bx.cx().immediate_backend_type(arg.layout); return local(OperandRef { val: OperandValue::Immediate(bx.cx().const_undef(backend_type)), layout: arg.layout, }); } </del> <ins> PassMode::Ignore(IgnoreMode::CVarArgs) => {} </ins> PassMode::Direct(_) => { let llarg = bx.get_param(bx.llfn(), llarg_idx as c_uint); bx.set_value_name(llarg, &name);

Discussion:
This example prints when compiled and run in debug mode: Compiling and running in release mode causes a segfault in  because is nul. Enabling debug info in release mode via makes the segfault go away.
thanks for reporting this. The example should probably look more like the following. The example still segfaults (even in debug mode). If is used in the function the issue does not happen. Essentially we're optimizing to the following Note the missing and . I think this is happening because we're hitting . I'll do some more investigation shortly.
the code I list in the above example should work after is merged.
Change:
backtrace = [] debug-jemalloc = ["alloc_jemalloc/debug"] jemalloc = ["alloc_jemalloc"] <ins> force_alloc_system = [] </ins> panic-unwind = ["panic_unwind"]

Discussion:
Edit: see Seems to get past there fine if I remove .
Ok, works. That's the version rustbuild will download if left to its own devices. Bisecting built nightlies as my local rust gives this: nightly-2016-12-19 () - works [no nightlies] nightly-2016-12-29 - unrelated errors on some i128/u128 stuff before it gets to the relevant point [no nightlies] nightly-2017-01-04 () - broken
Note that this is really quick to reproduce (~1min), as it happens on the initial build of stage0 std. Here's the full log from : This issue may get a lot more attention once the stage0 downloaded compiler has its version bumped, as I suspect will be totally broken. Applying seems to fix it.
Ah I see, the more recent compiler is being detected as a local rebuild compiler, so rustbuild assumes it has a compiler with stage1 features and therefore performs a stage1 build, which seems to assume that jemalloc is available. On a positive note, this should never affect someone not using .
Ok I have a more solid understanding of the issue. Currently, a stage0-out libstd will never link against jemalloc. stage1-out is left to its own devices, linking against the default allocator for the compiler that's just been created (stage0-out) which is , system otherwise. However, a local rebuild uses for building the stage0 libstd, which means it uses the default allocator for the local rust. This tends to be we've disabled jemalloc, so it hasn't been built! Something along the lines of seems like the right approach, but I think some elaboration around the logic in this area is necessary in comments or something.
Change:
let entry = entry.or_insert_with(|| { (FxHashSet::default(), FxHashSet::default(), Vec::new()) }); <del> entry.0.insert(cause.span); </del> <ins> entry.0.insert(cause_span); </ins> entry.1.insert((ident.span, "")); <del> entry.1.insert((cause.span, "unsatisfied trait bound introduced here")); </del> <ins> entry.1.insert((cause_span, "unsatisfied trait bound introduced here")); </ins> entry.2.push(p); } Some(node) => unreachable!("encountered `{node:?}`"),

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized via  and some manual item deletion: I can take a quick look into this one I guess. claim
Change:
<ins> // check-pass pub extern crate self as name; pub use name::name as bug; fn main() {} </ins>

Discussion:
Attempting to compile this code: Playground link: Causes this ICE in nightly 2019-12-29 ,and stable with a slightly different stack trace.
reduced to 2 lines: also, when the is removed from the line, OR both 's are removed, it compiles fine.
yeah, I prepared the fix but has already submitted another fix so assignment is unnecessary?
Change:
let mut polonius_prec = PoloniusOutOfScopePrecomputer::new(body, regioncx); for (loan_idx, loan_data) in borrow_set.iter_enumerated() { let issuing_region = loan_data.region; <del> let issued_location = loan_data.reserve_location; </del> <ins> let loan_issued_at = loan_data.reserve_location; </ins> polonius_prec.precompute_loans_out_of_scope( loan_idx, issuing_region, <del> issued_location, </del> <ins> loan_issued_at, </ins> ); }

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
} // FIXME: currently we never try to compose autoderefs // and ReifyFnPointer/UnsafeFnPointer, but we could. <del> _ => bug!( "while adjusting {:?}, can't compose {:?} and {:?}", expr, entry.get(), adj </del> <ins> _ => self.tcx.sess.delay_span_bug( expr.span, &format!( "while adjusting {:?}, can't compose {:?} and {:?}", expr, entry.get(), adj ), </ins> ), }; *entry.get_mut() = adj;

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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 --
searched toolchains through Regression in probably cc
I can look into this claim
Change:
/// # Examples /// /// ``` <del> /// #![feature(int_bits_const)] </del> #[doc = concat!("assert_eq!(", stringify!($SelfT), "::BITS, ", stringify!($BITS), ");")] /// ``` <del> #[unstable(feature = "int_bits_const", issue = "76904")] </del> <ins> #[stable(feature = "int_bits_const", since = "1.51.0")] </ins> pub const BITS: u32 = $BITS; /// Converts a string slice in a given base to an integer.

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
//~| HELP prefix with `field@` /// Link to [field@S::A] <del> //~^ ERROR incompatible link kind for `S::A` //~| NOTE this link resolved </del> <ins> //~^ ERROR unresolved link to `S::A` //~| NOTE this link resolves </ins> //~| HELP prefix with `variant@` pub fn f() {}

Discussion:
I'm probably planning on working on this, I found it while I was working on . The issue is that rustdoc looks up in the value namespace, which returns a Ctor, not a Variant. Turns out giving doc comments unimpeded access to the rustc resolver might not be a perfect idea This seems slightly (but not very) tricky to fix, mainly an ironing out of semantics - do we pretend that in the value namespace doesn't exist? Or do we let you reference it, but taking care not to say that there's a conflict between (the constructor) and (the variant) and that you have to disambiguate it? <!-- 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. --(current master): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
i'm not sure why we would want this - you can't document the constructor separately from the variant, so i would expect rustdoc to hide it from intra-doc links
(or alternatively we could make an alias for )
First of all, I can reproduce this problem with a unit-like struct. Second of all, This is an observable fact. To see it, use glob exports. Most crates probably won't do this... but most crates probably won't need disambiguators at all. These things are in the value namespace, and that's a fact that can be observed in the surface language, so we probably shouldn't pretend otherwise.
Change:
Def(kind, id) => Ok(Res::Def(kind, id)), PrimTy(prim) => Ok(Res::Primitive(PrimitiveType::from_hir(prim))), // e.g. `#[derive]` <del> NonMacroAttr(..) | Err => Result::Err(()), </del> <ins> ToolMod | NonMacroAttr(..) | Err => Result::Err(()), </ins> other => bug!("unrecognized res {:?}", other), } }

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
extern "rust-call" fn b(_i: i32) {} //~^ ERROR A function with the "rust-call" ABI must take a single non-self argument that is a tuple <ins> trait Tr { extern "rust-call" fn a(); extern "rust-call" fn b() {} //~^ ERROR A function with the "rust-call" ABI must take a single non-self argument } struct Foo; impl Foo { extern "rust-call" fn bar() {} //~^ ERROR A function with the "rust-call" ABI must take a single non-self argument } impl Tr for Foo { extern "rust-call" fn a() {} //~^ ERROR A function with the "rust-call" ABI must take a single non-self argument } </ins> fn main () { b(10); <ins> Foo::bar(); <Foo as Tr>::a(); <Foo as Tr>::b(); </ins> }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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 --
This crashes on master/nightly but not on
This is an overlooked case for , I can add it to the type-checking claim
I couldn't find a regression-from-beta-to-nightly label so using label +regression-from-stable-to-nightly
How did this not get caught by CI?
Assigning and removing as in the prioritization working group.
How did this not get caught by CI? I guess the original code (which triggers the ice) got changed. I found this by running todays rustc on the testcases from a couple of releases/years ago. :)
Yep, the test case was changed as part of the original PR. I didn't think to add the trait case to the new test, I've fixed that oversight (And one or two other possible cases) in the fix.
Regression is on beta now.
Change:
<ins> error: couldn't read the file --> $DIR/extented-attribute-macro-error.rs:4:10 | LL | #![doc = include_str!("../not_existing_file.md")] |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>

Discussion:
Note that must not exist in order to reproduce this error: The first error is what I would expect, but the second is a bit confusing and weird: Perhaps instead of emitting (/ERROR/)delayspanbug` since an error should have already occurred. If for some reason an error had not already been emitted, the compiler would crash; otherwise, it would just show the original error. Originally posted by in
Note that is stable now (though it hasn't reached the stable channel yet), so this no longer requires a feature flag.
Mentoring instructions: in , check if the token is a and the expression is an error; if so, use instead of .
Hi I was searching for a first issue and i have a question : What does ? Because the function that you pin must return a but has return type Sorry if i misread something
delayspanbug means "if the compiler finishes running without first reporting another error, panic". It's useful here because error tokens should always report in an error being reported. I think anything you return is probably fine as long as it doesn't cause further cascading errors :)
i fixed it but for adding a test case : i run into an edge case the output message of the macro : include_str! is not normalized with $DIR the ui test is working only for me. Have you a tip or i have to create an issue ? Thanks
you can use : https://rustc-dev- But I'm surprised $DIR doesn't work :/ that does seem like a bug.
Sorry I was not clear : the $DIR is working for the But the path is not replace for the error comment in the because the path read by include_str is in the error message
don't put the whole name in the .rs file - you just need to put a substring. Something like .