jiebi/CodeConvo huggingface dataset:
Code change:
#[doc(keyword = "CookieMonster")] pub mod keyword {} <ins> /// Just some type alias. pub type SomeType = u32; </ins>

Related discussion:
text: : Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.
Code change:
} }; <del> if let Some(path) = path && let Ok(mut out) = crate::fs::File::options().create(true).append(true).open(&path) { write(&mut out, BacktraceStyle::full()); } </del> if let Some(local) = set_output_capture(None) { <del> write(&mut *local.lock().unwrap_or_else(|e| e.into_inner()), backtrace); </del> <ins> write(&mut *local.lock().unwrap_or_else(|e| e.into_inner())); </ins> set_output_capture(Some(local)); } else if let Some(mut out) = panic_output() { <del> write(&mut out, backtrace); </del> <ins> write(&mut out); </ins> } }

Related discussion:
text: slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.
Code change:
<ins> // aux-build:issue-66286.rs // Regression test for #66286. extern crate issue_66286; #[issue_66286::vec_ice] pub extern fn foo(_: Vec(u32)) -> u32 { //~^ ERROR: parenthesized type parameters may only be used with a `Fn` trait 0 } fn main() {} </ins>

Related discussion:
text: Follow up to and , as per Minimize a test that exercises the same codepath as
As already stated in the proc macro can be reduced to:
How do you write a UI test that depends on 3rd-party libraries?
is an example of a test that relies on a procmacro, and we can use snippet for the necessary proc_macro being tested.
Code change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-android: FIXME(#9116) Bus error </del> use std::mem; #[repr(packed)]

Related discussion:
text: Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Code change:
actual: Ty<'tcx>, ti: TopInfo<'tcx>, ) -> Option<DiagnosticBuilder<'tcx, ErrorGuaranteed>> { <del> self.demand_eqtype_with_origin(&self.pattern_cause(ti, cause_span), expected, actual) </del> <ins> let mut diag = self.demand_eqtype_with_origin(&self.pattern_cause(ti, cause_span), expected, actual)?; if let Some(expr) = ti.origin_expr { self.suggest_fn_call(&mut diag, expr, expected, |output| { self.can_eq(self.param_env, output, actual).is_ok() }); } Some(diag) </ins> } fn demand_eqtype_pat(

Related discussion:
text: <!-- 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. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest to the user that they need to initialize the enum variant's value in order to use the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix
Code change:
infer::RelateOutputImplTypes(_) => "mismatched types", infer::MatchExpressionArm(_, _) => "match arms have incompatible types", infer::IfExpression(_) => "if and else have incompatible types", <ins> infer::IfExpressionWithNoElse(_) => "if may be missing an else clause", </ins> }; self.tcx.sess.span_err(

Related discussion:
text: I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:
Code change:
<ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>

Related discussion:
text: Spawned off of When passing to rustc I would expect all paths that start with to be replaced with , instead a is still present. Note that this happens even in release mode, because rustc always tells the msvc linker to generate files. This can be "fixed" by passing either , or to rustc, but doing so will break backtraces with ( already prints almost nothing in release mode). As a sidenote, do we really need backtraces in release mode, and by consequence files? They will break anyway if only the is distributed or the directory is deleted. Moreover this shouldn't be needed in the first place since promises to "remap source names in all output (compiler messages and output files)" (from the output of ), "including ). Also note that neither nor the rustc book mention the need to pass one of those arguments to rustc to remap/remove the path to the file, which makes it harder for non-experts to know how to remove them. :
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Perhaps this should be amended to say compiler output but not linker outputs. PDB files are generated at the linking step, which is probably why sees non-determinism for --crate-type=bin (linked) and not for --crate-type=rlib (not linked). Passing to the linker to put a relative path to the PDB files is probably the best choice, as it is the least destructive, and the debugger will look for PDB files next to the executables, so it will be able to find it. Chromium uses this for its Windows linking step as well: ;drc=;l=2358 Doing this with could work if you can figure out which "to-be-remapped" path is going to be the path being written by the linker, and then pass the resulting path to . I must confess I am not sure how linking is being done, but I assume the binary is being linked by a dedicated linker, not by rustc itself? If so that is not too reliable. rustc could provide a switch to remove the absolute path to PDB files, which would just map to . The value proposition there seems low, since you can pass that as the user anyway.
Code change:
<ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>

Related discussion:
text: Determinism is important for both release and debug builds, so I don't believe there is anything release-mode specific here or that a solution should be chosen that doesn't deal with debug mode? Could you say what is breaking about backtraces with ?
Without that flag I get something like: <details<summaryBacktrace</summary<p</p</detailsBut with it it just prints: <details<summaryBacktrace</summary<p</p</detailsThis seems to happen because the pdb file is searched relative to the current working directory, and when running that's often not the directory with the executable and pdb files. appears to work, but only as long as you execute it from the crate root, which is definitely not ideal.
Can move to the crate root before executing the target executable? Then cargo could pass (or debug) while other build systems pass or whatever works for them?
Wouldn't that break any workflow that relies on the current working directory always being where is executed from?
I think this meant the crate root instead of the cwd? I had no idea that would be a common thing, but you're right. It would change any use of . I would expect to be more commonly used for relative paths, as it doesn't depend on running from a cargo source tree, but maybe I am wrong. Regardless, I can see why changing behaviour isn't ideal. The MSVC linker doesn't present a whole lot of options though, as the path relative to where you plan to run the binary has to be encoded into the pdb files if you want a deterministic output. It seems the options are: -determinisic output, backtraces always work, debuggers work: PDB absolute paths. This is the default behaviour. output, , and backtraces work from the exe's directory: output, backtraces work from the crate root, but debuggers won't work: Have I missed an option? There's no option that I can see with both deterministic output and backtraces working from arbitrary working directories. AIUI, this github issue is about --remap-path-prefix not adding a flag, essentially. It would be nice if deterministic builds were easier to get!
Code change:
<ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>

Related discussion:
text: But based on all of the above, it seems to me that is better solved through Cargo than through rustc's , perhaps behind a Cargo flag in As a convenience, maybe could provide an option to move to the exe's directory to run it, instead of users doing , which would let option 2 be more ergonomic while also supporting debuggers.
Would it be possible to have create a symbolic link to the file or the directory when it's not already present in the current working directory? This would partially solve the ergonomic problems of approaches 2 and 3
It'd probably be easier to have set , which effect the default search path for the used for
Any update on this? :)
I've just opened which solves the problem by making always pass to the linker. This seems like the best solution to me. The PR is currently blocked on backtrace-rs not handling this properly, but I've opened , which will hopefully fix that.
Code change:
); } else { // Trivial case: `T` needs an extra bound: `T: Bound`. <del> let (sp, suggestion) = match super_traits { None => predicate_constraint( </del> <ins> let (sp, suggestion) = match ( generics .params .iter() .filter( |p| !matches!(p.kind, hir::GenericParamKind::Type { synthetic: Some(_), ..}), ) .next(), super_traits, ) { (_, None) => predicate_constraint( </ins> generics, trait_ref.without_const().to_predicate(tcx).to_string(), ), <del> Some((ident, bounds)) => match bounds { [.., bound] => ( bound.span().shrink_to_hi(), format!(" + {}", trait_ref.print_only_trait_path().to_string()), ), [] => ( ident.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), }, </del> <ins> (None, Some((ident, []))) => ( ident.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), (_, Some((_, [.., bounds]))) => ( bounds.span().shrink_to_hi(), format!(" + {}", trait_ref.print_only_trait_path().to_string()), ), (Some(_), Some((_, []))) => ( generics.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), </ins> }; err.span_suggestion_verbose(

Related discussion:
text: The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)
Code change:
LLC_$(1)=$$(CFG_LLVM_INST_DIR_$(1))/bin/llc$$(X_$(1)) LLVM_ALL_COMPONENTS_$(1)=$$(shell "$$(LLVM_CONFIG_$(1))" --components) <ins> LLVM_VERSION_$(1)=$$(shell "$$(LLVM_CONFIG_$(1))" --version) </ins> endef

Related discussion:
text: I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!
Code change:
///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

Related discussion:
text: The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in
Code change:
///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

Related discussion:
text: While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.
Code change:
///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

Related discussion:
text: When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.
Code change:
///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

Related discussion:
text: As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)
Code 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. #![feature(conservative_impl_trait)] fn foo() -> impl Copy { foo } fn main() { foo(); } </ins>

Related discussion:
text: Code works cc
Bug triage: on current nightly (), this no longer is an ICE, but yields the following error:
Code change:
LL |     foo::<_, L>([(); L + 1 + L]); |     ^^^^^^^^^^^ <del> error: aborting due to 5 previous errors </del> <ins> error: unconstrained generic constant `{const expr}` --> $DIR/issue_114151.rs:17:5 | LL |     foo::<_, L>([(); L + 1 + L]); |     ^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: aborting due to 6 previous errors </ins> Some errors have detailed explanations: E0107, E0308. For more information about an error, try `rustc --explain E0107`.

Related discussion:
text: we should change the following function to use a instead of Using a walker causes the control-flow to be a lot more complicated and given that this code is soundness-critical, we should make sure it's as easy to understand as possible <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim