jiebi/CodeConvo huggingface dataset:
Code change:
/// # Examples /// /// ```rust <del> /// #![feature(fmt_as_str)] /// </del> /// use std::fmt::Arguments; /// /// fn write_str(_: &str) { /* ... */ }

Related discussion:
text: Tracking issue for (), gated by .
I don't quite understand fmt internals, but Make fmt::Arguments::asstr() return a 'static str. seems unnecessarily restrictive. And it breaks which depends on hidden apis e.g. Arguments::newv1
cannot be generated at runtime because it cannot safely be done. So returns makes sense.
I'd like to be able to use this in the log crate to correctly implement a codegen optimization that doesn't really work otherwise: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
This SGTM. One question though. Are we sure that the bound will always be correct here?
is the result from parsing a formatting string at compile time. In the future, this might not always be a literal but might be a too. But a non-static/constant format string will be a very different beast.
That's what I figured, but wanted to make sure it was explicitly addressed.
:bell: This is now entering its final comment period, as per the . :bell:
Does this make any guarantees about when is returned? I've been interested in redoing the macro to be much more intelligent (and thus performant), but obviously don't know when it's possible to return something statically knowable.
Currently it returns Some for only. But my plan is to extend that also to , , and possibly also things like , etc. See
Yeah, I see that from looking at the source code. I was more inquiring about whether it would be considered breaking to go from returning to returning . I don't suspect anything would be out-of-reach when reimplementing the macro, but you never know.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Code change:
/// # Examples /// /// ```rust <del> /// #![feature(fmt_as_str)] /// </del> /// use std::fmt::Arguments; /// /// fn write_str(_: &str) { /* ... */ }

Related discussion:
text: I think you'd generally want to use it as an optimization only, but we can probably guarantee that it will return Some for certain cases in particular (e.g. ).
This function seems particularly bad for compressed formatting strings and breaks the otherwise clean abstraction.
Code change:
let fty = self.sanitize_type(place, fty); match self.field_ty(place, base, field, location) { Ok(ty) => { <ins> let ty = self.cx.normalize(ty, location); </ins> if let Err(terr) = self.cx.eq_types( ty, fty,

Related discussion:
text: According to my CI this started 2020-04-16 (https://travis-) - : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reports a regression in (PR ), cc
Assigning as and removing .
assign
Oh dear, I was hoping crater will find all such issues (this is ). I guess nobody in the wild is pattern-matching tuples with non-literal-length arrays. I can repro by adding this line () to the test (and the PR fixing this should IMO add the line to ): The fix is likely trivial: add another normalization, like in Presumably, for field accesses, this time (weird that doesn't trigger the bug). <hr/I've brought it up before w/ (but I don't know if I've seen a response), that the lack of normalization for array lengths in typeck is pushing complexity to the rest of the compiler and maybe we should do it in typeck. But then again, Lazy Normalization Is Coming, so maybe there's no point.
I believe I responded in the PR where you already asked me about that. I'm fine reintroducing a normalization phase
Code change:
} fn visit_rvalue(&mut self, rvalue: &mut Rvalue<'tcx>, location: Location) { <del> if let Some(mtbl) = self.optimizations.and_stars.remove(&location) { </del> <ins> if self.optimizations.and_stars.remove(&location) { </ins> debug!("replacing `&*`: {:?}", rvalue); let new_place = match rvalue { Rvalue::Ref(_, _, place) => {

Related discussion:
text: Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.
Code change:
} }; let attrs = &item.attrs; <del> let sp = span_of_attrs(attrs); </del> <ins> let sp = span_of_attrs(attrs).unwrap_or(item.source.span()); </ins> let mut diag = cx.tcx.struct_span_lint_hir( lint::builtin::INTRA_DOC_LINK_RESOLUTION_FAILURE,

Related discussion:
text: crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.
Code change:
nightly ) msg "overriding settings for $CFG_RELEASE_CHANNEL" CFG_ENABLE_LLVM_ASSERTIONS=1 <del> CFG_ENABLE_DEBUGINFO_LINES=1 </del> <ins> # FIXME(#37364) shouldn't have to disable this on windows-gnu case "$CFG_BUILD" in *-pc-windows-gnu) ;; *) CFG_ENABLE_DEBUGINFO_LINES=1 ;; esac </ins> ;; beta | stable) msg "overriding settings for $CFG_RELEASE_CHANNEL" <del> CFG_ENABLE_DEBUGINFO_LINES=1 </del> <ins> case "$CFG_BUILD" in *-pc-windows-gnu) ;; *) CFG_ENABLE_DEBUGINFO_LINES=1 ;; esac </ins> ;; dev) ;;

Related discussion:
text: Failure happens in the crate: This probably has to do with how we're calling the "custom resume" function, unsure what's going on.
Duplicate of
Indeed!
Code change:
let trait_to_placeholder_args = impl_to_placeholder_args.rebase_onto(tcx, impl_m.container_id(tcx), trait_to_impl_args); <ins> let hybrid_preds = tcx .predicates_of(impl_m.container_id(tcx)) .instantiate_identity(tcx) .into_iter() .chain(tcx.predicates_of(trait_m.def_id).instantiate_own(tcx, trait_to_placeholder_args)) .map(|(clause, _)| clause); let param_env = ty::ParamEnv::new(tcx.mk_clauses_from_iter(hybrid_preds), Reveal::UserFacing); let param_env = traits::normalize_param_env_or_error( tcx, param_env, ObligationCause::misc(tcx.def_span(impl_m_def_id), impl_m_def_id), ); </ins> let infcx = &tcx.infer_ctxt().build(); let ocx = ObligationCtxt::new(infcx); // Normalize the impl signature with fresh variables for lifetime inference. <del> let norm_cause = ObligationCause::misc(return_span, impl_m_def_id); </del> <ins> let misc_cause = ObligationCause::misc(return_span, impl_m_def_id); </ins> let impl_sig = ocx.normalize( <del> &norm_cause, </del> <ins> &misc_cause, </ins> param_env, tcx.liberate_late_bound_regions( impl_m.def_id,

Related discussion:
text: This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc
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. // Check that we cannot have two sequence repetitions in a row. macro_rules! foo { ( $($a:expr)* $($b:tt)* ) => { }; //~ ERROR sequence repetition followed by another sequence ( $($a:tt)* $($b:tt)* ) => { }; //~ ERROR sequence repetition followed by another sequence } fn main() { } </ins>

Related discussion:
text: In an example like we report the following error: This is part of the macro future-proofing code but it is an unnecessary limitation. For fragments that represent at most one token tree (, , , possibly others) there is no concern at all about being following by sequence repetition. This turns out to be a really big limitation in practice, since making macros that work over a generic sequence of token trees effectively allows for arbitrary parsing. cc
triage: P-medium
I'd be happy to mentor this, if I don't fix it first.
triage: P-medium
cc
I-ICE?
Curious why this was closed, looks like it's blocking lispy-rust.
It was fixed by ; do you still see this issue present in nightly?
Code change:
// #[rustc_main] let main_attr = ecx.attr_word(sym::rustc_main, sp); <ins> // #[no_coverage] let no_coverage_attr = ecx.attr_word(sym::no_coverage, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

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. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- 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<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected .
Code change:
// #[rustc_main] let main_attr = ecx.attr_word(sym::rustc_main, sp); <ins> // #[no_coverage] let no_coverage_attr = ecx.attr_word(sym::no_coverage, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

Related discussion:
text: However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.
Code change:
(Some(Mode::ToolRustc), "rust_analyzer", None), (Some(Mode::ToolStd), "rust_analyzer", None), (Some(Mode::Codegen), "parallel_compiler", None), <ins> // NOTE: consider updating `check-cfg` entries in `std/Cargo.toml` too. // cfg(bootstrap) remove these once the bootstrap compiler supports // `lints.rust.unexpected_cfgs.check-cfg` </ins> (Some(Mode::Std), "stdarch_intel_sde", None), (Some(Mode::Std), "no_fp_fmt_parse", None), (Some(Mode::Std), "no_global_oom_handling", None),

Related discussion:
text: With extra verbose flag (), one would see a lots of warnings about check-cfg when building -Zbuild-std. But it doesn't need to be that way. Can we doodfooding check-cfg flag to and to resolve them? Step to reproduce: I expected to see this happen: No warnings about " unexpected " Some are: label +F-check-cfg +-Zbuild-std cc
Code change:
write!(w, "{}", impl_header)?; for implementor in local { <del> write!(w, "<li><code>")?; </del> <ins> write!(w, "<li>")?; if let Some(item) = implementor2item(&cache, implementor) { if let Some(l) = (Item { cx, item }).src_href() { write!(w, "<div class='out-of-band'>")?; write!(w, "<a class='srclink' href='{}' title='{}'>[src]</a>", l, "goto source code")?; write!(w, "</div>")?; } } write!(w, "<code>")?; </ins> // If there's already another implementor that has the same abbridged name, use the // full path, for example in `std::iter::ExactSizeIterator` let use_absolute = match implementor.impl_.for_ {

Related discussion:
text: It should work a bit like IDE's feature that finds everything that implements a given interface.
This should be a fairly small change (the most annoying part has already been done) so i'll open this up as a mentored issue. The bit that writes out the "Implementors" section is in . This is where the known implementors for a given trait are pulled out of the global context and listed out onto the rendered page. The bit that's responsible for creating links is , implemented on a local type. This kind of Item is easily made from the kind of Item that's otherwise worked on in , but there's a catch: The entries in the Implementors list aren't s. They're s, which are only a subset of the things you get on an Item. This is the "most annoying part" i mentioned earlier. Fortunately, i ran into this when creating the "Implementations on Foreign Types" section, so if you scroll up a little in , you can see so i could render the full impl block for them. The task for anyone who wants to take this on is to pull that up a little so that it's used for all the implementors, not just the foreign ones. With a in hand, combine it with the Context to create a and call to generate the link. ( This also helpfully includes the extra HTML bits that will flush the link to the right edge, which is really the final step.) And... that's it! The link should probably go between the and the where clause underneath it, so that it's aligned with the impl line and not the where clause. You may need to also close/open the that's wrapping the whole line to make sure the link itself isn't monospace. If you have any questions, let me know! Either comment here, or hop onto IRC in , or the impl period Gitter under .
Code change:
// extensions <ins> pub fn get_args(&self) -> &[OsString] { &self.args } </ins> pub fn take_args(&mut self) -> Vec<OsString> { mem::replace(&mut self.args, Vec::new()) }

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:
// extensions <ins> pub fn get_args(&self) -> &[OsString] { &self.args } </ins> pub fn take_args(&mut self) -> Vec<OsString> { mem::replace(&mut self.args, Vec::new()) }

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:
find_testable_code(&dox, &mut tests, ErrorCodes::No); if check_missing_code == true && tests.found_tests == 0 { <del> let sp = span_of_attrs(&item.attrs).substitute_dummy(item.source.span()); </del> <ins> let sp = span_of_attrs(&item.attrs).unwrap_or(item.source.span()); </ins> let mut diag = cx.tcx.struct_span_lint_hir( lint::builtin::MISSING_DOC_CODE_EXAMPLES, hir_id,

Related discussion:
text: crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.