jiebi/CodeConvo huggingface dataset:
Code change:
HTML_DEPS := endif <del> # Check for the various external utilities for the EPUB/PDF docs: ifeq ($(CFG_LUALATEX),) $(info cfg: no lualatex found, deferring to xelatex) ifeq ($(CFG_XELATEX),) $(info cfg: no xelatex found, deferring to pdflatex) ifeq ($(CFG_PDFLATEX),) $(info cfg: no pdflatex found, disabling LaTeX docs) NO_PDF_DOCS = 1 else CFG_LATEX := $(CFG_PDFLATEX) endif else </del> <ins> # Check for xelatex ifeq ($(CFG_XELATEX),) </ins> CFG_LATEX := $(CFG_XELATEX) XELATEX = 1 <del> endif else CFG_LATEX := $(CFG_LUALATEX) </del> <ins> else $(info cfg: no xelatex found, disabling LaTeX docs) NO_PDF_DOCS = 1 </ins> endif ifeq ($(CFG_PANDOC),) $(info cfg: no pandoc found, omitting PDF and EPUB docs) ONLY_HTML_DOCS = 1

Related discussion:
text: Same error, with the last github version.
Also getting this, I'm running the Yosemite GM 1. Not sure if it's related.
I also getting this on MacOs
Still getting this make error, like many others did. Anyone want to fix this?
I have no idea how to fix this, other than just installing xetex or however it's spelled
The configure(or make) did find LuaTeX.
Sadly I don't have time to work on this right now. A simple fix would be to disable pdf generation unless specified in configure, or to require xetex.
I don't think that LaTeX should be a dependency to build a programming language like Rust.
it seems reasonable to have the option to not build PDF docs if you don't want to
I think I'm getting the same error, which is strange because I believe I was able to a couple days ago. In the log, the complaint is that is not found. As suggested above, is included with MacPorts' package and installing that allowed compilation of docs to go through.
will build without building the PDF docs
Code change:
Some(ns @ TypeNS) => { match self.resolve( path_str, <ins> disambiguator, </ins> ns, &current_item, base_node,

Related discussion:
text: I tried to document this code: I expected to see this happen: charstd::char` points to module page of char type points to char primitive page Instead, this happened: type points to module page of char :
I think the problem is that modules are in the type namespace, so is doing exactly what you are asking it for (the module, since it has higher priority). Since the built-in types scope is the lowest precedence, perhaps there needs to be a way to access it directly? Maybe something like or ? Or maybe should skip over modules, and keep looking deeper in the scope hierarchy? (cc )
Oh hmm I see what you mean. There are : Types, values, and macros. Since modules and types are in the same namespace, it uses the first one it finds. Maybe we could work around this by first resolving in an empty module (so it has nothing in scope), then only falling back to the current scope if we don't find something there?
I'm surprised this hasn't caused trouble before now. Does the root of never use the primitive?
I don't know how it works, but the resolver is smart enough to know that in a type context won't match a module (like , the won't match a module named "char". Maybe it has something to do with late-resolution  which has a to give it some context?
Adding that would be more of area ... I can give it a shot though.
It looks like doesn't even return a resolution and only records it for later use ... I'm going to go with the empty module workaround and we can fix it later if it turns out to cause issues.
The double resolve seems hacky. We could probably make type@ specifically not resolve to a module, perhaps? Also, note that modules are in all namespaces
How would that work? We could skip any module resolutions, but since modules have precedence over types I don't know how we'd get the primitive type to resolve afterwards.
Oh hold on we have a function already. We can look at directly.
This doesn't have anything to do with primitives, this has to do with glob imports vs non-glob imports. You can get the same issue with the following:
This also doesn't have to do with modules being "resolved first" or anything. Things that are non-glob in-scope are resolved first.
Code change:
Some(ns @ TypeNS) => { match self.resolve( path_str, <ins> disambiguator, </ins> ns, &current_item, base_node,

Related discussion:
text: Actually, my bad: This does have to do with primitives in the sense that primitives are the only thing that still work when shadowed because of some special code in checking the primitive tables. I think when the string matches one of the primitive table entries for TypeNS lookups that were explicitly annotated with type@ and resolve to a module we can hack this in. In the future we might want to tighten up this code so that e.g. can't resolve to an enum, etc.
do you mind if I fix at the same time and resolve primitives even before modules? That seems like the less surprising behavior to me, the module can still be disambiguated with .
I'm a bit wary of doing this because having the char module in scope is not a common situation, and it will get weirder for people who have a different char module. I think we should resolve to whatever is in scope, but if is explicitly mentioned we can then force resolve to the primitive.
Code change:
| KeywordItem => [].iter(), } } <ins> /// Returns `true` if this item does not appear inside an impl block. pub(crate) fn is_non_assoc(&self) -> bool { matches!( self, StructItem(_) | UnionItem(_) | EnumItem(_) | TraitItem(_) | ModuleItem(_) | ExternCrateItem { .. } | FunctionItem(_) | TypedefItem(_) | OpaqueTyItem(_) | StaticItem(_) | ConstantItem(_) | TraitAliasItem(_) | ForeignFunctionItem(_) | ForeignStaticItem(_) | ForeignTypeItem | MacroItem(_) | ProcMacroItem(_) | PrimitiveItem(_) ) } </ins> } #[derive(Clone, Debug)]

Related discussion:
text: From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.
Code change:
| KeywordItem => [].iter(), } } <ins> /// Returns `true` if this item does not appear inside an impl block. pub(crate) fn is_non_assoc(&self) -> bool { matches!( self, StructItem(_) | UnionItem(_) | EnumItem(_) | TraitItem(_) | ModuleItem(_) | ExternCrateItem { .. } | FunctionItem(_) | TypedefItem(_) | OpaqueTyItem(_) | StaticItem(_) | ConstantItem(_) | TraitAliasItem(_) | ForeignFunctionItem(_) | ForeignStaticItem(_) | ForeignTypeItem | MacroItem(_) | ProcMacroItem(_) | PrimitiveItem(_) ) } </ins> } #[derive(Clone, Debug)]

Related discussion:
text: Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.
Code change:
# Find out where the pretty printer Python module is RUSTC_SYSROOT="$("$RUSTC" --print=sysroot)" GDB_PYTHON_MODULE_DIRECTORY="$RUSTC_SYSROOT/lib/rustlib/etc" <ins> # Get the commit hash for path remapping RUSTC_COMMIT_HASH="$("$RUSTC" -vV | sed -n 's/commit-hash: (w*)/1/p')" </ins> # Set the environment variable `RUST_GDB` to overwrite the call to a # different/specific command (defaults to `gdb`).

Related discussion:
text: I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.
Code change:
padding: 5px 10px; } h5, h6 { <del> color: black; </del> text-decoration: underline; }

Related discussion:
text: When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.
Code change:
fn output_filename(&mut self, path: &Path) { self.cmd.arg("-o").arg(path); } fn add_object(&mut self, path: &Path) { self.cmd.arg(path); } fn position_independent_executable(&mut self) { self.cmd.arg("-pie"); } <ins> fn no_position_independent_executable(&mut self) { self.cmd.arg("-no-pie"); } </ins> fn partial_relro(&mut self) { self.linker_arg("-z,relro"); } fn full_relro(&mut self) { self.linker_arg("-z,relro,-z,now"); } fn build_static_executable(&mut self) { self.cmd.arg("-static"); }

Related discussion:
text: I'm having trouble linking a Rust program to a non-position-independent C library. When I manually remove the flag from the ld step that rustc runs, everything works correctly. I think that should remove the flag for me, but it doesn't. Here's what I think is going on: When I run It runs ld with the flag: But when I read the rustc code , it seems like the intention is that should only be passed to ld when . That is, if we're not compiling a position independent executable, then we should not pass the position independent executable flag to ld. I think what may be happening here is that somehow the defaults from are overriding the command line options I'm setting. This happens with stable and also the nightly I tried:
and are two distinct things. is also unrelated to the option. Interestingly, I do not remember us having an option to disable PIE; we should have one.
I did a bit of reading and here's what I figured out, please correct me if any of this is wrong. Linkers are new to me! Rust builds position independent executables by default on platforms that support it. These platforms have a relocation model of pic in their target config. The is what sets that linker option, except if it's disallowed by . The correct solution to this is to add a codegen flag, or something like that. Does this sound right?
Hi, I am having the same issue. I am trying to link against non-position-independent C library, build process ends without error but results returned by Rust bindings are different (and incorrect) than those returned from clean C implementation. In order to overcome that issue currently I am setting RUSTFLAGS="-C relocation-model=dynamic-no-pic -C linker=./linker" where linker is bash script that wraps cc and filter -pie flags:
I'm also having this problem. I assumed that passing when doing a build would suppress on the linker command line. (cc:
I'm still seeing this issue. Not sure if it's a regression or I'm doing something wrong. I have a "hello world" program in , and when I run , the resulting call to includes . I'm using nightly rust on Ubuntu: .
So, the problem here isn't with rust, but with the linker.
Code change:
fn output_filename(&mut self, path: &Path) { self.cmd.arg("-o").arg(path); } fn add_object(&mut self, path: &Path) { self.cmd.arg(path); } fn position_independent_executable(&mut self) { self.cmd.arg("-pie"); } <ins> fn no_position_independent_executable(&mut self) { self.cmd.arg("-no-pie"); } </ins> fn partial_relro(&mut self) { self.linker_arg("-z,relro"); } fn full_relro(&mut self) { self.linker_arg("-z,relro,-z,now"); } fn build_static_executable(&mut self) { self.cmd.arg("-static"); }

Related discussion:
text: In Ubuntu 15.10 and later the default GCC toolchain installed has been compiled with which causes and to be passed to during code generation and to during linking. Now, the linking part is what is important here as rust on most platforms uses as the linker for most targets. So, though no PIC or PIE code may have been generated by , the linker will still try to link as with PIE in mind, breaking when trying to compile with and the like. To work around this will need to see that the linker has been compiled with PIE as the default and pass to the linker if using GCC or something similar for other linkers. Code to do this can be seen in for Tarpaulin though it is only meant for Linux in that state and can be improved greatly if in tree. EDIT: Don't know why Github isn't linking cross-project PRs correctly right now.
Can this issue be resolved by always passing , except when compiling with ?
Sadly, no. In testing I have seen that any build of GCC that was not built with rejects the option and fails to run. This is why in the PR that I linked the linker was queried to see if it was compiled with before tacking on .
So it's came out from the discussion on an issue related to this in tarpaulin that passing -no-pie before -shared (and maybe then -static if it exists for static linkages as well) resolves the issue. I'm going to test this tarpaulin side and I can report back but I feel it would be best if this could be solved rustc side as it can affect any user in a similar situation.
Code change:
// We errored. Signal that in the pattern, so that follow up errors can be silenced. let kind = PatKind::Error(e); return Box::new(Pat { span: self.span, ty: cv.ty(), kind }); <ins> } else if let ty::Adt(..) = cv.ty().kind() && matches!(cv, mir::Const::Val(..)) { // This branch is only entered when the current `cv` is `mir::Const::Val`. // This is because `mir::Const::ty` has already been handled by `Self::recur` // and the invalid types may be ignored. let err = TypeNotStructural { span: self.span, non_sm_ty }; let e = self.tcx().sess.emit_err(err); let kind = PatKind::Error(e); return Box::new(Pat { span: self.span, ty: cv.ty(), kind }); </ins> } else if !self.saw_const_match_lint.get() { if let Some(mir_structural_match_violation) = mir_structural_match_violation { match non_sm_ty.kind() {

Related discussion:
text: <!-- 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. --: This bug was also reproduced in the stable version(1.72) <!-- 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 --
claim
Hmm this was caused by cc
claim
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. #![allow(dead_code)] struct Foo; impl Foo { fn new() -> Self { Foo } fn bar() { Self::new(); } } fn main() {} </ins>

Related discussion:
text: The following code will fail to compile at "Self::new()" with the message, "error: failed to resolve. Use of undeclared type or module " While either of the following will work: The first example should compile as-is.
Code change:
<ins> use crate::infer::outlives::components::{compute_components_recursive, Component}; </ins> use crate::infer::outlives::env::RegionBoundPairs; use crate::infer::region_constraints::VerifyIfEq; use crate::infer::{GenericKind, VerifyBound}; use rustc_data_structures::captures::Captures; use rustc_data_structures::sso::SsoHashSet; use rustc_hir::def_id::DefId; <del> use rustc_middle::ty::subst::{GenericArg, GenericArgKind, Subst}; </del> <ins> use rustc_middle::ty::subst::{GenericArg, Subst}; </ins> use rustc_middle::ty::{self, EarlyBinder, Ty, TyCtxt}; <ins> use smallvec::smallvec; </ins> /// The `TypeOutlives` struct has the job of "lowering" a `T: 'a` /// obligation into a series of `'a: 'b` constraints and "verifys", as /// described on the module comment. The final constraints are emitted

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. --I tried this code: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
Code change:
fn outer(self) { fn inner(_: Self) { //~^ ERROR can't use type parameters from outer function <del> //~^^ ERROR use of undeclared type name `Self` </del> <ins> //~^^ ERROR use of `Self` outside of an impl or trait </ins> } } }

Related discussion:
text: is a keyword, this error message indicates that it can be used to define type, which is misleading.
There is a similar issue: file.
No, that's a different issue. At the time that issue was filed, was not a keyword, just a confusing type. That said, at the time that issue was reported, it's fine to say the compiler was implemented properly. But my issue is about wrong error message, not bad(confusing) error message.
Do you mean is not a special ident now? I found the example code can be compiled, and there is excluding self type code
My point is that we are in different situation now. See and notice that it happened after the time the issue we discuss was filed.
Actually, IIRC we're moving towards a direction where can be used everywhere in a trait or impl context. I'm not sure though. any idea?
Yes we can use it in traits or impls. is totally legal for instance. But inside global functions can not be explained if I understand correctly.
Oh, sorry, this was a global fn. Makes sense.
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 Foo: Sized { fn foo(self) {} } trait Bar: Sized { fn bar(self) {} } struct S; impl<'l> Foo for &'l S {} impl<T: Foo> Bar for T {} fn main() { let s = S; s.foo(); (&s).bar(); s.bar(); } </ins>

Related discussion:
text: Consider this code: The error is: It'd be nice if the explicit ref wasn't required in this case.
cc
This has now been fixed.
I believe this is covered by
Code change:
use rustc::hir::def::{Res, DefKind}; use rustc::hir::def_id::DefId; use rustc::lint; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::adjustment; use rustc_data_structures::fx::FxHashMap; use lint::{LateContext, EarlyContext, LintContext, LintArray};

Related discussion:
text: gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:
Code change:
#[primary_span] pub item_span: Span, #[suggestion(code = "unsafe ", applicability = "machine-applicable", style = "verbose")] <del> pub block: Span, </del> <ins> pub block: Option<Span>, </ins> } #[derive(Diagnostic)]

Related discussion:
text: With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?