jiebi/CodeConvo huggingface dataset:
Code change:
pub struct BufWriter<W: Write> { inner: Option<W>, buf: Vec<u8>, <ins> // #30888: If the inner writer panics in a call to write, we don't want to // write the buffered data a second time in BufWriter's destructor. This // flag tells the Drop impl if it should skip the flush. panicked: bool, </ins> } /// An error returned by `into_inner` which combines an error that

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

Related discussion:
text: I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened
Code change:
use std::env; <del> use bootstrap::{Build, Config, Subcommand}; </del> <ins> use bootstrap::{Build, Config, Subcommand, VERSION}; </ins> fn main() { let args = env::args().skip(1).collect::<Vec<_>>(); let config = Config::parse(&args); <del> let changelog_suggestion = check_version(&config); </del> <ins> // check_version warnings are not printed during setup let changelog_suggestion = if matches!(config.cmd, Subcommand::Setup {..}) { None } else { check_version(&config) }; </ins> // NOTE: Since `./configure` generates a `config.toml`, distro maintainers will see the // changelog warning, not the `x.py setup` message.

Related discussion:
text: New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.
Code change:
let path_data = match path_data { Some(pd) => pd, None => { <del> span_bug!(path.span, "Unexpected def kind while looking up path in `{}`", self.span.snippet(path.span)) </del> <ins> return; </ins> } };

Related discussion:
text: STR: run with on a program with a name resolution error. Result: cc (bug manifests in the RLS)
I can take this. I already dug into some time ago, I encountered the same bug when I was trying to write a refactoring tool. To fix the issue, I have to remove all the around there, right ?
great, thanks for digging in. There's likely to be some s that don't need to be there, but it won't be quite as simple as just ripping them out. There will be some error condition that needs to be dealt with.
Code change:
<ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/implied-bounds-unnorm-associated-type-3.rs:19:5 | LL |     fn zero_copy_from<'b>(cart: &'b [T]) -> &'b [T] { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `T: 'static`... = note: ...so that the type `[T]` will meet its required lifetime bounds error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>

Related discussion:
text: Note: The regression is valid/"allowed" (there's a hole in the typesystem being patched), I'm just filing this issue now so we can make sure that this regression is tracked in case it got "fixed" by accident. Feel free to close if it's a known quantity; I'm just worried that this got "accidentally" fixed in some other change. My crate is being fixed to not face this problem, but in general there's a chance other crates are falling afoul of this as well; we should perhaps assess the impact and start off with it being a future incompatibility warning if necessary. I tried this code: () I expected to see this happen: It compiles, like it does on stable, or at least throws a future incompatibility warning. Instead, this happened: It errors: It most recently worked on: Rust 1.56.0
This regressed in , which was a rollup. Further testing shows this resulted from . It's marked as being a partial revert, so I'm not entirely sure what the chronology is here. CC Note that we think this "regression" probably isn't actually a problem, per the note at the top.
What the....
Okay so reverting fully also errors. Stable 1.55.0 fails. Checking (a couple commits before ) now, but I'm assuming it's going to error. So, this was actually a bug in 1.56.0 - prior to that, this didn't compile, rightfully. My guess is because of treating unnormalized function args & output as WF, we saw , replaced it with , assumed that was WF, so we didn't actually check that . I'm going to go ahead and make a PR to add a test that closes this issue. This was a bug in 1.56.0, not a regression since.
Good to know, thanks! (And good that this was just a one-version regression; less chance of there being in-the-wild breakage)
I should figure out an excuse to make yoke a dependency of rustc, it seems really good at finding typesystem corner cases and maybe we should just have it be a test
Isn't it failing on the wrong line?
Code change:
<ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/implied-bounds-unnorm-associated-type-3.rs:19:5 | LL |     fn zero_copy_from<'b>(cart: &'b [T]) -> &'b [T] { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `T: 'static`... = note: ...so that the type `[T]` will meet its required lifetime bounds error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>

Related discussion:
text: I would have expected it to fail on the because is the thing that needs to match
Haha yeah, it's a thorn in my side So, it's interesting. The check is , which is true. What I might expect here is it to fail because you haven't written (which is required for to be well-formed. But I think this is implied bounds, since this is fine:
In my experience WFness of has always been a bit variable where sometimes you can assume it and sometimes it requires you to spell it out, so maybe this is another instance of that.
Thanks!
Code change:
<del> struct Bug([u8; panic!(1)]); //~ ERROR panicking in constants is unstable </del> <ins> // Note: non-`&str` panic arguments gained a separate error in PR #80734 // which is why this doesn't match the issue struct Bug([u8; panic!("panic")]); //~ ERROR panicking in constants is unstable </ins> fn main() {}

Related discussion:
text: The panic payload of the macro (as passed on to ) is generic, but the CTFE panic support assumes it will always be an . This leads to ICEs: Cc
I guess we could support this, but we'd have to find some way to render the errors. Maybe we need to wait for const traits so we can require const Debug?
Alternatively constck could require the argument to have type .
also requires a
Yeah, the libcore panic machinery does not support non-format-string panics.
Aye, left out the latter of my message. is likely the most common argument to , and it's not unusual with e.g. ; so I agree that waiting for const traits before supporting any other arguments is reasonable.
Im hitting this ICE on stable without feature flag:
Hm indeed, that is interesting: any idea why we go on here after seeing an error? Does this kind of behavior mean any part of CTFE is reachable on stable somehow?
yes. We're not gating CTFE on whether there were stability (or any other static checks) failing. I've been abusing this since 1.0 to demo things on the stable compiler and never got around to fixing it. I don't even know if we have a tracking issue for it.
:rofl: So what would be a possible approach here? Replace such consts by early enough that their MIR never actually gets evaluated? We might as well use this issue, IMO...
That would require us to mutate all MIR and potentially even HIR. Other possible solutions: poison the mir Body if const checks fail (by adding a field like or by just nuking the body by replacing it with ) and thus make allow const evaluation to check if the mir Body failed the checks and bail out before doing anything make the have an field similar to
On second thought, let's leave this issue for the ICE, and make a new one for "we can trigger nightly-only const code on stable because we don't abort compilation early enough":
Given that this ICE is pre-existing, as shown by , can we un-block ? I'd really like to see const_panic stabilized, and this seems like a minor issue to be blocking on.
That comment is an example of accidentally partially exposing an unstable feature on stable -- a separate bug tracked in I don't see how that's an argument for shipping that feature on stable when it is broken.
Code change:
<del> struct Bug([u8; panic!(1)]); //~ ERROR panicking in constants is unstable </del> <ins> // Note: non-`&str` panic arguments gained a separate error in PR #80734 // which is why this doesn't match the issue struct Bug([u8; panic!("panic")]); //~ ERROR panicking in constants is unstable </ins> fn main() {}

Related discussion:
text: In particular, applies to all unstable const features. Fixing this bug here is not even that hard I think: somewhere around here there needs to be a check that the argument has type . Re: , AFAIK that one is also blocked on figuring out how the diagnostics should look like, and a further concern (though maybe not blocking) is .
I guess that might make this a non-issue, where it is proposed also would require as first argument.
For reference: , which was recently merged. The plan is to fix the behaviour of in the Rust 2021 edition. Given that this ICE is listed as a blocker for , does this mean that stabilizing that will have to wait for the next edition?
No, because breaking changes are allowed to be made to unstable features without moving to a new edition; that's kinda the whole idea. The 2021 edition will effectively just extend the same restriction to all invocations, const context or not.
I'd like to tackle this but I'm not very experienced with the CTFE code. I get that we need to check from the that we've matched on in this branch and we need to match on the enum, but: For the first question, I see and that we probably want to check that the type of the tuple and that there's variants of that are , but do we stop the iteration when we get one that is a type? Is the projection list always guaranteed to terminate in a variant of that has a ? And once we have an instance of , do we just check that there's any_ projection in the list that has a ?
you can use to get the type of the . Then you can test its to be .
Code change:
asm_args: cvs!["-mthumb-interwork", "-march=armv4t", "-mlittle-endian",], // minimum extra features, these cannot be disabled via -C <del> features: "+soft-float,+strict-align".into(), </del> <ins> // Also force-enable 32-bit atomics, which allows the use of atomic load/store only. // The resulting atomics are ABI incompatible with atomics backed by libatomic. features: "+soft-float,+strict-align,+atomics-32".into(), </ins> panic_strategy: PanicStrategy::Abort, relocation_model: RelocModel::Static,

Related discussion:
text: If you try to compile the crate with , it fails with the following error: This seems to be a regression from to , and my best guess for the change that caused it is this pull request: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Filed to fix this. FYI, a short-term workaround is to enable the target feature (). claim
Possibly related: This is seen cross-compiling from Linux to Windows. Giant 1MB linker error message related to atomicload, only in release mode, for target x8664-pc-windows-gnu. Failing in rustc 1.67.1 stable. Currently asking for help comments; will file an issue in a day or two if nobody reports a known fix.
Since native atomic ops exist in x86_64, I don't believe this and are related to your problem. Given that rend3 has enabled , your problem may be related to
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: I got this while trying to implement something similar to a FromStr trait and tried to rely on a lot of inferencing when calling it. I can try to extract a standalone example if needed.
This ICE is also producible by trying to refer to an associated type that's never defined. is accepted by the compiler when it clearly should not be - what on earth is ? The following and code cases the same ICE. Here's the stack trace:
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: I get the ICE below when I compile this fragment of code: The above structs are defined here: The above fragment is part of That crate depends on And that crate requires erlang-17.4 to be installed.
A minimal program to demonstrate the crash is...
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait { type A; type B; } fn foo<T: Trait<A = T::B>>() { } //~^ ERROR: unsupported cyclic reference between types/traits detected fn main() { } </ins>

Related discussion:
text: compile with opt-level = 2 (works fine with opt-level=0)
strange. the program looks legit to me.
this works for me now, as of
This prints on all opt levels for me at .
Code change:
ConditionalPass::always(CHECK_CUSTOM_CODE_CLASSES), ConditionalPass::always(COLLECT_TRAIT_IMPLS), ConditionalPass::always(CHECK_DOC_TEST_VISIBILITY), <ins> ConditionalPass::always(STRIP_ALIASED_NON_LOCAL), </ins> ConditionalPass::new(STRIP_HIDDEN, WhenNotDocumentHidden), ConditionalPass::new(STRIP_PRIVATE, WhenNotDocumentPrivate), ConditionalPass::new(STRIP_PRIV_IMPORTS, WhenDocumentPrivate),

Related discussion:
text: I tried this code: with and . I expected to see this happen: No internal fields of the should be displayed as users won't be able to use the fields, making their appearance confusing and useless. Instead, this happened: The internal fields of the are displayed ! Real impact as can be seen . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
labels +T-rustdoc +A-rustdoc-ui -needs-triage claim
Dupe of and more discussion there