jiebi/CodeConvo huggingface dataset:
Change:
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)):  $$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_RUNTIME_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@ $$(HLIB$(2)_H_$(4))/$(CFG_CORELIB_$(4)):  $$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_CORELIB_$(4))  $$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@ # Subtle: We do not let the shell expand $(CORELIB_DSYM_GLOB) directly rather

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
<ins> //! Test that we don't allow coercing an opaque type with a non-static //! lifetime to one with a static lifetime. While `get_iter` looks like //! it would be doing the opposite, the way we're handling projections //! makes `Opaque<'a>` the hidden type of `Opaque<'static>`. #![feature(type_alias_impl_trait)] mod defining_scope { pub type Opaque<'a> = impl Sized; fn get_one<'a>(a: *mut &'a str) -> Opaque<'a> { a } } use defining_scope::Opaque; fn get_iter<'a>() -> impl IntoIterator<Item = Opaque<'a>> { None::<Opaque<'static>> //~^ ERROR lifetime may not live long enough } fn main() {} </ins>

Discussion:
The following should not compile. Adapted from . This is a quick issue, I did not have the chance to look into it deeper but I guess it affects ATPIT as well. cc
This used to be an error in , but then incorrectly accepted in .
Change:
use crate::base::*; use crate::config::StripUnconfigured; use crate::errors::{ <del> EmptyDelegationMac, GlobDelegationOutsideImpls, IncompleteParse, RecursionLimitReached, RemoveExprNotSupported, RemoveNodeNotSupported, UnsupportedKeyValue, WrongFragmentKind, </del> <ins> EmptyDelegationMac, GlobDelegationOutsideImpls, GlobDelegationTraitlessQpath, IncompleteParse, RecursionLimitReached, RemoveExprNotSupported, RemoveNodeNotSupported, UnsupportedKeyValue, WrongFragmentKind, </ins> }; use crate::mbe::diagnostics::annotate_err_with_kind; use crate::module::{mod_dir_path, parse_external_mod, DirOwnership, ParsedExternalMod};

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' 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: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for functions --> $DIR/bad-infer-in-trait-impl.rs:6:15 | LL |     fn bar(s: _) {} |               ^ not allowed in type signatures | help: use type parameters instead | LL |     fn bar<T>(s: T) {} |           +++    ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </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. --<!-- 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
Minimal:
label +S-bug-has-mcve
Change:
} fn parse_expr_path_start(&mut self) -> PResult<'a, P<Expr>> { <ins> let maybe_eq_tok = self.prev_token.clone(); </ins> let (qself, path) = if self.eat_lt() { <del> let (qself, path) = self.parse_qpath(PathStyle::Expr)?; </del> <ins> let lt_span = self.prev_token.span; let (qself, path) = self.parse_qpath(PathStyle::Expr).map_err(|mut err| { // Suggests using '<=' if there is an error parsing qpath when the previous token // is an '=' token. Only emits suggestion if the '<' token and '=' token are // directly adjacent (i.e. '=<') if maybe_eq_tok.kind == TokenKind::Eq && maybe_eq_tok.span.hi() == lt_span.lo() { let eq_lt = maybe_eq_tok.span.to(lt_span); err.span_suggestion(eq_lt, "did you mean", "<=", Applicability::Unspecified); } err })?; </ins> (Some(qself), path) } else { (None, self.parse_path(PathStyle::Expr)?)

Discussion:
The simplest reproduction would be something like this: the `note points at the operator A new user might get confused about needing a type, as the error points at the number instead of the comparator. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
mod test_json_encode_decode { use serialize::json::ToJson; use super::Target; <del> $(use super::$module;)* </del> <ins> $(use super::$module;)+ </ins> $( #[test]

Discussion:
There are actually two different generally expected encodings of the host tuple and they're subtly different than what some might expect. For example, 'x8664-sun-solaris' should probably be x8664-pc-solaris. The reason for that is that the encoding schemes are actually: So while 'sparcv9-sun-solaris' is correct because Sun is the (historical) manufacturer of sparc CPUs, 'x8664-sun-solaris' is not, because the MANUFACTURER here is the manufacturer of the CPU not the operating system. There are special cases for this, for example 'x8664-apple-darwin', even though Apple doesn't make x8664 CPUs, but following gcc/clang conventions leads us to x8664-pc-solaris. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
/cc /cc
An interesting discrepancy here is that our target and the LLVM target currently don't match. I'm not sure whether we can/should change anything here for backwards compatibility reasons, though an alias seems fine.
Hi, can I take this issue up? Can someone give a hint on how to fix this? I am a rust beginner, interested in compilers. This would be my first contribution.
as far as I can tell, you should just be able to add a new line under: containing , and then add a new line under: containing: (Sorry for the delay: I only just saw your message.)
claim
I wonder how it's supposed to work? Only x86_64-sun-solaris continues work for me: This change make it harder for Mozilla Firefox to decide which target to use...
I think we may have to introduce some changes in to make rustc try to use the alias. I.e. should try to use the target . I haven't had time to look into what else needs to be changed.
Closing as a duplicate of
Change:
<ins> // Copyright 2014 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. struct Baz<U> where U: Eq(U); //This is parsed as the new Fn* style parenthesis syntax. struct Baz<U> where U: Eq(U) -> R; // Notice this parses as well. struct Baz<U>(U) where U: Eq; // This rightfully signals no error as well. struct Foo<T> where T: Copy, (T); //~ ERROR unexpected token in `where` clause struct Bar<T> { x: T } where T: Copy //~ ERROR expected item, found `where` fn main() {} </ins>

Discussion:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.
Change:
// An Arc to the packet is stored into a `JoinInner` which in turns is placed // in `JoinHandle`. struct Packet<'scope, T> { <del> scope: Option<&'scope scoped::ScopeData>, </del> <ins> scope: Option<Arc<scoped::ScopeData>>, </ins> result: UnsafeCell<Option<Result<T>>>, <ins> _marker: PhantomData<Option<&'scope scoped::ScopeData>>, </ins> } // Due to the usage of `UnsafeCell` we need to manually implement Sync.

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
<ins> -include ../../run-make-fulldeps/tools.mk all: EXISTING_ENV=1 EXISTING_OPT_ENV=1 $(RUSTC) --emit dep-info main.rs $(CGREP) "# env-dep:EXISTING_ENV=1" < $(TMPDIR)/main.d $(CGREP) "# env-dep:EXISTING_OPT_ENV=1" < $(TMPDIR)/main.d $(CGREP) "# env-dep:NONEXISTENT_OPT_ENV" < $(TMPDIR)/main.d $(CGREP) "# env-dep:ESCAPEnESCAPE" < $(TMPDIR)/main.d </ins>

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
<ins> // Copyright 2018 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. // run-rustfix #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> { Ok(1) } fn forbidden_narratives() -> Result<isize, ()> { missing_discourses()? //~^ ERROR try expression alternatives have incompatible types //~| HELP try wrapping with a success variant } fn main() {} </ins>

Discussion:
Given this example: I get this error (): It seems like it should not be talking about =)
Ideally, I would think it should say something like "missing ", but that may be a separate bug -- i.e., maybe we should strive to just produce the same error you would get if you did
Change:
}; let (sopts, cfg) = config::build_session_options_and_crate_config(&matches); <del> hygiene::set_default_edition(sopts.edition); </del> driver::spawn_thread_pool(sopts, |sopts| { run_compiler_with_pool(matches, sopts, cfg, callbacks, file_loader, emitter_dest)

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
<ins> error[E0616]: field `foo` of struct `S` is private --> $DIR/issue-90483-inaccessible-field-adjustment.rs:11:18 | LL |   || s.foo() + s.foo; |                  ^^^ private field | help: a method `foo` also exists, call it with parentheses | LL |   || s.foo() + s.foo(); |                     ++ error: aborting due to previous error For more information about this error, try `rustc --explain E0616`. </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. --<!-- 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. --: Also checked beta and nightly at : <!-- 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 does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.
Change:
let pat_id = pattern.id; walk_pat(pattern, |pattern| { match pattern.node { <del> PatIdent(binding_mode, ref path1, _) => { // The meaning of pat_ident with no type parameters </del> <ins> PatIdent(binding_mode, ref path1, ref at_rhs) => { // The meaning of PatIdent with no type parameters </ins> // depends on whether an enum variant or unit-like struct // with that name is in scope. The probing lookup has to // be careful not to emit spurious errors. Only matching // patterns (match) can match nullary variants or <del> // unit-like structs. For binding patterns (let), matching // such a value is simply disallowed (since it's rarely // what you want). </del> <ins> // unit-like structs. For binding patterns (let // and the LHS of @-patterns), matching such a value is // simply disallowed (since it's rarely what you want). let const_ok = mode == RefutableMode && at_rhs.is_none(); </ins> let ident = path1.node; let renamed = mtwt::resolve(ident); match self.resolve_bare_identifier_pattern(ident.name, pattern.span) { <del> FoundStructOrEnumVariant(def, lp) if mode == RefutableMode => { </del> <ins> FoundStructOrEnumVariant(def, lp) if const_ok => { </ins> debug!("(resolving pattern) resolving `{}` to  struct or enum variant", renamed);

Discussion:
This is accepted, but probably shouldn't be. (A normal declaration of a variable named None is rejected.)
Related testcase:
That second case is unrelated. (And really weird, I'm not even sure how that's happening!)
Change:
<ins> #include <stdio.h> #include <stdint.h> typedef union TestUnion { uint64_t bits; } TestUnion; uint64_t give_back(TestUnion tu) { return tu.bits; } </ins>

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me
Change:
} fn add_flags(&mut self, flags: TypeFlags) { <del> self.flags = self.flags | (flags & TypeFlags::NOMINAL_FLAGS); </del> <ins> self.flags = self.flags | flags; </ins> } /// indicates that `self` refers to something at binding level `binder`

Discussion:
This seems to contain all the flags in . If I'm guessing right, the flags that used to not be in here, all turned into queries? So they're now cached as queries, instead of by mutating itself? cc
If it contains all the flags, then it seems to have no purpose. I'm honestly not sure what the name "nominal" is even meant to refer to here exactly -- I'm sure I gave it that name, but it's not very clear. I guess the point is "flags that should be inherited by containing types; ie., if the type has some flag , and is "nominal", then should also have ". Are there any flags that don't meet that definition anymore?
I think there were "nominal flags" and "cached properties" (using interior mutability), but now the latter is completely gone.
that sounds right. I'd be in favor of removing then.
I would love to help with this one. A quick search shows that is only used once in the entire code base, here: Looks like this could just be changed to Is that all it will take?
Sounds correct, yeah.
Cool great
Oops, I'm still learning git. Sorry for the spam there. Only is relevant.
Change:
} let is_generic = match path.res { <del> Res::PrimTy(p) => match p { hir::PrimTy::Str => return Primitive(PrimitiveType::Str), hir::PrimTy::Bool => return Primitive(PrimitiveType::Bool), hir::PrimTy::Char => return Primitive(PrimitiveType::Char), hir::PrimTy::Int(int_ty) => return Primitive(int_ty.into()), hir::PrimTy::Uint(uint_ty) => return Primitive(uint_ty.into()), hir::PrimTy::Float(float_ty) => return Primitive(float_ty.into()), }, </del> <ins> Res::PrimTy(p) => return Primitive(PrimitiveType::from(p)), </ins> Res::SelfTy(..) if path.segments.len() == 1 => { return Generic(kw::SelfUpper.to_string()); }

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.