jiebi/CodeConvo huggingface dataset:
Change:
span: sp(0,21)}))); } <ins> #[test] fn parse_use() { let use_s = "use foo::bar::baz;"; let vitem = string_to_view_item(use_s.to_string()); let vitem_s = view_item_to_string(&vitem); assert_eq!(vitem_s.as_slice(), use_s); let use_s = "use foo::bar as baz;"; let vitem = string_to_view_item(use_s.to_string()); let vitem_s = view_item_to_string(&vitem); assert_eq!(vitem_s.as_slice(), use_s); } #[test] fn parse_extern_crate() { let ex_s = "extern crate foo;"; let vitem = string_to_view_item(ex_s.to_string()); let vitem_s = view_item_to_string(&vitem); assert_eq!(vitem_s.as_slice(), ex_s); let ex_s = "extern crate "foo" as bar;"; let vitem = string_to_view_item(ex_s.to_string()); let vitem_s = view_item_to_string(&vitem); assert_eq!(vitem_s.as_slice(), ex_s); } </ins> fn get_spans_of_pat_idents(src: &str) -> Vec<Span> { let item = string_to_item(src.to_string()).unwrap();

Discussion:
method will unconditionally fail if it encounters a view item ( or ). This is desired behavior if parsing the body of a function. However, there are no public methods that allow parsing either of these items individually. This makes it impossible to parse the full range of possible input to a REPL. If it's acceptable, I could make a pull request for public methods (which already exists, privately) and .
Change:
s.print_mod(&krate.module, &krate.attrs); s.print_remaining_comments(); <ins> s.ann.post(&mut s, AnnNode::Crate(krate)); </ins> s.s.eof() }

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
html_root_url = "http://static.rust-lang.org/doc/master")]; #[feature(macro_rules, globs, managed_boxes)]; <del> #[allow(unknown_features)]; #[feature(quote_expr)]; </del> <ins> #[allow(unknown_features)];// Note: remove it after a snapshot. #[feature(quote)]; </ins> #[deny(non_camel_case_types)];

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
lint_opaque_hidden_inferred_bound = opaque type `{$ty}` does not satisfy its associated type bounds .specifically = this associated type bound is unsatisfied for `{$proj_ty}` <del> .suggestion = add this bound </del> <ins> lint_opaque_hidden_inferred_bound_sugg = add this bound </ins>

Discussion:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.
Change:
$$(CTEST_TESTARGS) CTEST_DEPS_rpass_$(1)-T-$(2)-H-$(3) = $$(RPASS_TESTS) <del> CTEST_DEPS_rpass_full_$(1)-T-$(2)-H-$(3) = $$(RPASS_FULL_TESTS) $$(TLIBRUSTC_DEFAULT$(1)_T_$(2)_H_$(3)) </del> <ins> CTEST_DEPS_rpass-full_$(1)-T-$(2)-H-$(3) = $$(RPASS_FULL_TESTS) $$(CSREQ$(1)_T_$(2)_H_$(3)) </ins> CTEST_DEPS_rfail_$(1)-T-$(2)-H-$(3) = $$(RFAIL_TESTS) CTEST_DEPS_cfail_$(1)-T-$(2)-H-$(3) = $$(CFAIL_TESTS) CTEST_DEPS_bench_$(1)-T-$(2)-H-$(3) = $$(BENCH_TESTS)

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.
Change:
} impl<'a, I, O: 'a> Parser<'a, I, O> { <del> fn compose<K: 'a>(mut self, mut rhs: Parser<O, K>) -> Parser<'a, I, K> { </del> <ins> fn compose<K: 'a>(mut self, mut rhs: Parser<'a, O, K>) -> Parser<'a, I, K> { </ins> Parser { parse: box move |&mut: x: I| { match self.parse.call_mut((x,)) {

Discussion:
If you pass an immutable reference through two structs, one of which is a trait, you can take an immutable reference to a variable that will be mutated later, and the compiler will compile. For a proof of concept, see , and if you want to see it in an actual use case, see (look in the main file). I don't know if this is an issue or not, it didn't cause any safety issues when I used it. Is there a rust-ier way of doing the type of thing I did in the second example (allow an immutable reference to a value that will be mutated, in order to see the new value).
The whole thing in one piece: Thanks for filing, these memory safety bugs are very important to catch, however, I think this may be a duplicate of another bug which I cannot find right now (iirc was interacting with those other bugs). I believe the underlying problem here is the function is invalid, the boxing/returning that happens should be disallowed without the having the lifetime too.
FWIW, I’ve reduced the issue a little more ():
Nominating
As I posted on IRC, this is a variance problem - is unsoundly bivariant:
Thanks for cutting it down. I still am not a good Rust programmer, so I was just copying, as close as I could, the original, accidental, version.
cc
P-backcompat-lang, 1.0.
seems to be dup of
I tested and this is indeed fixed by PR . Too bad I didn't look into this bug first rather than , since I see that other people already worked out the variance connection already.
Change:
"0xaa00000000006e1", "0x6e10aa", "0x1234567890123456", "0x5634129078563412", "0x6a2c48091e6a2c48", "[0x56, 0x34, 0x12, 0x90, 0x78, 0x56, 0x34, 0x12]", "[0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56]", "", "" } <del> widening_impl! { i64, i128, 64, signed } </del> } #[lang = "i128"]

Discussion:
I had this question on the currently unreleased ; on signed carry (probably applies to substraction too ?); I have this test failing with the current code: Playground: Is the test correct ? A carry did happen in an intermediate calculation, but should the overall calculation report a carry ?
I agree that this is a bug. There's a carry when the calculation is done as unsigned, but this is not the same in signed. Another example: That incorrectly returns .
There's some discussion about that in the tracking issue, starting with
Yeah, it looks like I rehashed the same arguments, that's what I get for reading comments and doc too fast. Still, I think that this is surprising enough that it would be nice to address it somehow.
I agree this is a bug. It looks like it's implementing the signed version using the unsigned one, returning the same carry flag (), but that's incorrect. Here's another demonstration that it needs an update: you be up to making a fix PR, You can use to get assigned to this issue.
I have no bandwidth for making a fix right now. Since this was supposed to be helpers for bigint operations, my first idea was to just remove the signed variants. I have no idea if this would be appropriate. Anyone is welcome to do a proper fix, it shouldn't be too complicated.
A thought: What should do? It feels to me like the carryout from that should perhaps be , since the carry from that is different from the one in , which would imply that it couldn't be anymore. We do have a type that's -1, 0, or 1: . I can't decide if that's clever or horrible. Or should we just delete the signed versions for now?
I think should return , because signed and unsigned operations should give the same results, so should be computed as which gives , then truncated to 8-bits which gives . Then because gives , which can't be represented as an 8-bits signed number, then there is overflow to me. Now for the -1, 0, 1 overflow, I don't think it's necessary because the point of the bit is to indicate if it happened or not. The direction of overflow is indicated by the resulting value. If I am correct, then this raises another question: should intermediate overflow be detected or not ?

for example: gives a result of -128, so the output is the same as the input so no overflow. But if we break down the operations, overflows to 127, and then overflows back to -128. In this case should an overflow occur or not ? Considering my previous example, I personally think it intermediate overflow shouldn't be detected because it would be misleading: it would indicate that the sign of the source operands and the result are different while they are the same. Tho I'd like other's opinion.
I think so. The unsigned versions have clear semantics, but it gets weird with signed values, and as a "bigint helper" I'd be surprised to see one that uses signed digits in the first place.
Change:
prev_token_before_parsing: Token, error: &mut Diag<'_>, ) { <del> if ((style == PathStyle::Expr && self.parse_paren_comma_seq(|p| p.parse_expr()).is_ok()) || (style == PathStyle::Pat && self </del> <ins> match style { PathStyle::Expr if let Ok(_) = self .parse_paren_comma_seq(|p| p.parse_expr()) .map_err(|error| error.cancel()) => {} PathStyle::Pat if let Ok(_) = self </ins> .parse_paren_comma_seq(|p| { p.parse_pat_allow_top_alt( None,

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Ah, of course, we want to the returned by .
I will try to remedy the situation. claim
Change:
} // FIXME(eddyb) should these really do nothing? StatementKind::FakeRead(..) | <del> StatementKind::SetDiscriminant { .. } | </del> StatementKind::StorageLive(_) | StatementKind::StorageDead(_) | StatementKind::InlineAsm {..} |

Discussion:
Leaving this issue as a reminder for It should be as simple as adding a checkplace call to the <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This bug appears in as well: Might as well stop letting inline ASM through to MIRI while you're at it.
I'm taking this one :P
assign
Change:
<ins> // aux-build: primitive-reexport.rs // compile-flags:--extern foo --edition 2018 #![crate_name = "bar"] // @has bar/p/index.html // @has - '//code' 'pub use bool;' // @has - '//code/a[@href="https://doc.rust-lang.org/nightly/std/primitive.bool.html"]' 'bool' // @has - '//code' 'pub use char as my_char;' // @has - '//code/a[@href="https://doc.rust-lang.org/nightly/std/primitive.char.html"]' 'char' pub mod p { pub use foo::bar::*; } // @has bar/baz/index.html // @has - '//code' 'pub use bool;' // @has - '//code/a[@href="https://doc.rust-lang.org/nightly/std/primitive.bool.html"]' 'bool' // @has - '//code' 'pub use char as my_char;' // @has - '//code/a[@href="https://doc.rust-lang.org/nightly/std/primitive.char.html"]' 'char' pub use foo::bar as baz; // @has bar/index.html // @has - '//code' 'pub use str;' // @has - '//code/a[@href="https://doc.rust-lang.org/nightly/std/primitive.str.html"]' 'str' // @has - '//code' 'pub use i32 as my_i32;' // @has - '//code/a[@href="https://doc.rust-lang.org/nightly/std/primitive.i32.html"]' 'i32' pub use str; pub use i32 as my_i32; </ins>

Discussion:
When re-exporting a primitive type, rustdoc ICEs. This was found when creating . Rustdoc also fails to link the re-export to the primitive docs. Reproduction: commands: Backtrace:
I plan on investigating this issue tomorrow, as it is likely a blocker for
-- this is blocking , and I was unable to come up with a simple patch to fix this. Is this a known-hard problem, or should I try to keep digging? contains my initial patch, but it fails tests (e.g., auto impls for primitives, among other problems).
I'll try to take a look shortly. And no, never heard of it before you opened this issue. Don't hesitate to ping me if I forget.
Change:
if !self.report_similar_impl_candidates( impl_candidates, trait_ref, <ins> obligation.cause.body_id, </ins> &mut err, ) { // This is *almost* equivalent to

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
} TerminatorKind::Call { func, args, destination, cleanup, .. } => { let func_ty = func.ty(&self.body.local_decls, self.tcx); <ins> let func_ty = self.tcx.normalize_erasing_regions(self.param_env, func_ty); </ins> match func_ty.kind() { ty::FnPtr(..) | ty::FnDef(..) => {} _ => self.fail(

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
None } } else { <ins> // HACK(#82501): on Windows, the tools directory gets added to PATH when running tests, and // compiletest confuses HTML tidy with the in-tree tidy. Name the in-tree tidy something // different so the problem doesn't come up. if tool == "tidy" { tool = "rust-tidy"; } </ins> let cargo_out = builder.cargo_out(compiler, self.mode, target).join(exe(tool, compiler.host)); let bin = builder.tools_dir(compiler).join(exe(tool, compiler.host));

Discussion:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.
Change:
trait_selection_inherent_projection_normalization_overflow = overflow evaluating associated type `{$ty}` <ins> trait_selection_invalid_format_specifier = invalid format specifier .help = no format specifier are supported in this position </ins> trait_selection_invalid_on_clause_in_rustc_on_unimplemented = invalid `on`-clause in `#[rustc_on_unimplemented]` .label = invalid on-clause here

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?
Change:
} let place = fragment.contents; <ins> let fragment = if fragment_layout.size == Size::ZERO { // Fragment is a ZST, so does not represent anything. continue; } else if fragment_layout.size == var_layout.size { // Fragment covers entire variable, so as far as // DWARF is concerned, it's not really a fragment. None } else { Some(fragment_start..fragment_start + fragment_layout.size) }; </ins> per_local[place.local].push(PerLocalVarDebugInfo { name: var.name, source_info: var.source_info, dbg_var, <del> fragment: if fragment_layout.size == var_layout.size { // Fragment covers entire variable, so as far as // DWARF is concerned, it's not really a fragment. None } else { Some(fragment_start..fragment_start + fragment_layout.size) }, </del> <ins> fragment, </ins> projection: place.projection, }); }

Discussion:
Building Firefox for the thumbv7neon-linux-androideabi and i686-linux-android fails with a rust compiler crash: I wish I could give something more detailed, but I haven't had the time to try to yet. I however identified the regression to come from (Enable ScalarReplacementOfAggregates in optimized builds) and building with avoids the crash.
Duplicate of
going to close as such. thanks for reporting !
Change:
<ins> warning: unused arithmetic operation that must be used --> $DIR/issue-64970.rs:13:9 | LL |         1i32 / n; |         ^^^^^^^^ | = note: `#[warn(unused_must_use)]` on by default </ins>

Discussion:
The following code results in a const eval divide by zero error, when it cannot actually error at runtime:
Bisected to , which corresponds to . cc BTW, you need to actually use (e.g. by calling it in ) to trigger the error. Just adding won't do it.
Fun thing, it doesn't even depend on the conditions in the if clause: also ICEs
Thanks
Change:
<ins> // run-pass #![feature(layout_for_ptr)] use std::mem; #[repr(packed, C)] struct PackedSized { f: u8, d: [u32; 4], } #[repr(packed, C)] struct PackedUnsized { f: u8, d: [u32], } impl PackedSized { fn unsize(&self) -> &PackedUnsized { // We can't unsize via a generic type since then we get the error // that packed structs with unsized tail don't work if the tail // might need dropping. let len = 4usize; unsafe { mem::transmute((self, len)) } } } fn main() { unsafe { let p = PackedSized { f: 0, d: [1, 2, 3, 4] }; let p = p.unsize() as *const PackedUnsized; // Make sure the size computation does *not* think there is // any padding in front of the `d` field. assert_eq!(mem::size_of_val_raw(p), 1 + 4*4); // And likewise for the offset computation. let d = std::ptr::addr_of!((*p).d); assert_eq!(d.cast::<u32>().read_unaligned(), 1); } } </ins>

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
else <del> $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)):  $$(TEST_SREQ$(1)_T_$(2)_H_$(3))  $$(CTEST_DEPS_$(4)_$(1)-T-$(2)-H-$(3)) </del> <ins> $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)): </ins> @$$(call E, run $(4) [$(2)]: $$<) <del> @$$(call E, warning: tests disabled: $$(CTEST_DISABLE_$(4))) </del> <ins> @$$(call E, warning: tests disabled: $$(CTEST_DONT_RUN_$(1)-T-$(2)-H-$(3)-$(4))) </ins> touch $$@ endif

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.