jiebi/CodeConvo huggingface dataset:
Code change:
let text = lines.collect::<Vec<&str>>().join("n"); if rendered { return } PLAYGROUND_KRATE.with(|krate| { <del> let mut s = String::new(); </del> <ins> // insert newline to clearly separate it from the // previous block so we can shorten the html output let mut s = String::from("n"); </ins> krate.borrow().as_ref().map(|krate| { let test = origtext.lines().map(|l| { stripped_filtered_line(l).unwrap_or(l)

Related discussion:
text: A documentation comment like the one cited verbatim below, produces a main page summary that includes the first line of the code in the example. This is very surprising since there's an empty line in between, and the code example inserts a large colored box in the overview page (the parent module). cc since it's probably related to PR /// A tuple or fixed size array that can be used to index an array. /// /// /// /// Note the blanket implementation that's not visible in rustdoc: /// !
Code change:
/// # Examples /// /// ``` <del> /// #![feature(osstring_ascii)] </del> /// use std::ffi::OsString; /// /// let mut s = OsString::from("GRÜßE, JÜRGEN ❤");

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] - Stabilized traits necessary to obtain [x] - Added ASCII methods on [x] Final commenting period (FCP) [x] - Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Just needed to manipulate paths on windows -- I need to lower case driver letter, -.
Currently, SQLx contains The UTF-8 check that is included in there, while not a problem in practice, seems pointless. Changing to lands me here because of the .
Code change:
/// # Examples /// /// ``` <del> /// #![feature(osstring_ascii)] </del> /// use std::ffi::OsString; /// /// let mut s = OsString::from("GRÜßE, JÜRGEN ❤");

Related discussion:
text: Also, if somebody did a similar thing with instead of , the version could drop that and would then be a bit less noisy.
is a stabilization PR. Since lib team wants to do fcp in the tracking issue. could you start one ?
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] [ ] Concerns: resolved by 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.
Slight question about -- normally when dealing with AsRef args, they come in without an explicit reference in the signature (), except when necessary to support a lifetime in the return value (). Currently is declared as: Is this supposed to be instead? concern eqignoreasciicase &amp;S
I think it should be. I'm not sure why I wrote it like I did originally, but this makes more sense to me. I can make that PR if needed. Or can it be done in the stabilization PR? Not sure what the process is from here.
resolve eqignoreascii_case &amp;S reviewed Fixed in .
:bell: This is now entering its final comment period, as per the . :bell:
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.
you can tick the FCP box, as the FCP is complete.
Code change:
<ins> #![feature(adt_const_params)] #![allow(incomplete_features)] use std::marker::ConstParamTy; #[derive(ConstParamTy)] //~^ the trait `ConstParamTy` cannot be implemented for this ty struct Foo([*const u8; 1]); #[derive(ConstParamTy)] //~^ the trait `ConstParamTy` cannot be implemented for this ty struct Foo2([*mut u8; 1]); #[derive(ConstParamTy)] //~^ the trait `ConstParamTy` cannot be implemented for this ty struct Foo3([fn(); 1]); fn main() {} </ins>

Related discussion:
text: The following code fails to compile, because using function pointers as const generics is forbidden: However, if the function pointer is inside an array, it suddenly compiles: Is this intentional, or should it also be forbidden? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The first is definitely intentional. have an unstable notion of equality, in particular if they point to instances of generic functions: two entirely independent functions might have "equal" function pointers if they happen to compile to the same assembly code, and two identical instances of the same generic function in different crates (or even just different codegen units) might compare "inequal".
The second is a bug, good catch! I misread the issue description at first. This should not work in arrays -- I assume this would be fixed by properly moving to valtrees. Cc
still compiles, the issue is that function pointers are currently considered to be structural match. I intend to work on structural equality in the near (not that near) future, going to assign this to myself. claim
Same issue with raw pointers (both and ):
This no longer works: Looks like the issue got fixed? We should make sure we have a test though.
this happens as const generics now relies on instead of simply using structural match.
Code change:
// crates they depend on. let rel_rpaths = get_rpaths_relative_to_output(os, output, libs); <ins> // Make backup absolute paths to the libraries. Binaries can // be moved as long as the crates they link against don't move. let abs_rpaths = get_absolute_rpaths(libs); </ins> // And a final backup rpath to the global library location. let fallback_rpaths = ~[get_install_prefix_rpath(target_triple)];

Related discussion:
text: These are configured something like
I am not sure why this happens off hand, but when bootstrapping the non-build-triple compilers artifacts are copied from e.g. to .
Code change:
|          - unclosed delimiter ... LL | fn foo() { <del> |          - unclosed delimiter ... LL | fn bar() { |          - unclosed delimiter </del> <ins> |          - another 3 unclosed delimiters begin from here </ins> ... <del> LL | fn baz() { |          - unclosed delimiter LL |     if false { </del> LL |         { |         - this delimiter might not be properly closed... LL |             && let () = ()

Related discussion:
text: In my Fedora installation ended up being a corrupted file. It took me hours to realize, given that the output does not bring any clarity to it. rustc should really have ratelimit detection or something to detect corrupted file instead and inform about this to the user. !
This indeed seems quite confusing; and counter-productive to try to show this blob of errors. Would you be able to provide us with a reproducible example of the issue? Or if you still have it the corrupted file. labels +T-compiler +A-diagnostics +D-verbose +D-confusing +S-needs-repro -needs-triage
So this a problem because I unfortunately deleted the trashed file before someone told me that I should report this as a bug. I regret that I did not store it :-/ BUT I recalled that it was probably for reason a long string of ANSI escape codes. So I did a test string: This creates somewhat similar output as I got, except probably the string was a bit longer in my case.
OK doubling that starts to be almost perfect match:
! ... I'm considering T-shirt design ;-) Made by me and rustc. EDIT: and rendered by excellent terminal emulator foot
Somehow rustc should be able to detect corrupted file in cargo's source repository (or whatever it is called). It was pretty bizarre sight when I encountered this by accident.
Thanks for the repro. label -S-needs-repro
Yeah I mean it is really a huge corner case but it can happen in the case of data corruption (e.g. power outage in middle of write operation). I'd detect frequency of errors and maybe a threshold parameter when it is interpreted as corruption with a sane default value.
yeah, I believe this error comes out from the phase of lexing, which rustc are trying to find all the mismatched delimiters, maybe a threshold is ok for resolve it.
Code change:
Ok(()) } <del> fn is_legal_fragment_specifier(sess: &ParseSess, features: &Features, attrs: &[ast::Attribute], </del> <ins> fn is_legal_fragment_specifier(_sess: &ParseSess, _features: &Features, _attrs: &[ast::Attribute], </ins> frag_name: &str, <del> frag_span: Span) -> bool { </del> <ins> _frag_span: Span) -> bool { /* * If new fragment specifiers are invented in nightly, `_sess`, * `_features`, `_attrs`, and `_frag_span` will be useful here * for checking against feature gates. See past versions of * this function. */ </ins> match frag_name { "item" | "block" | "stmt" | "expr" | "pat" | "lifetime" | <del> "path" | "ty" | "ident" | "meta" | "tt" | "vis" | "" => true, "literal" => { if !features.macro_literal_matcher && !attr::contains_name(attrs, "allow_internal_unstable") { let explain = feature_gate::EXPLAIN_LITERAL_MATCHER; emit_feature_err(sess, "macro_literal_matcher", frag_span, GateIssue::Language, explain); } true }, </del> <ins> "path" | "ty" | "ident" | "meta" | "tt" | "vis" | "literal" | "" => true, </ins> _ => false, } }

Related discussion:
text: Tracking issue for rust-lang/rfcs.
Is anyone working on implementation already? If not I can take a crack at it.
I'll probably do it.
Huh oh, we have an issue already: do we mean to include potentially minus-prefixed literals? If yes, we have a problem because 1. it means we have to return an Expr instead of a Lit, which means I'm not sure one will be able to use the bound fragment in a non-expr context (for example in a static array type?) and 2. it's no longer always a single-TT, so the benefits in terms of future-proofing are a bit less good. If we don't... well, we loose expressivity. I have no idea what is more intuitive though... Would you, as a Rust user, expect to parse ? I certainly can think of use cases for this...
good point. I think I would have expected it, I also agree with the complications.
Can't we upgrade Lit to support negative literals?
I'd expect "literal" (or a future integer-literal specifier) to include (negative 5), but not (the negation of positive 5). Perhaps that expectation doesn't match reality, though. For instance, based on parsing rules for non-literals, I'd expect to act like . So, if handling both and as literals makes this easier, that works. But "literal" definitely needs to include negative numbers, or we'd have a weird user trap to explain.
I'd expect "literal" (or a future integer-literal specifier) to include -5 (negative 5), but not - 5 (the negation of positive 5). Unary operators, including minus, are processed purely by the parser at the moment, no lexer involved. So their treatment is whitespace agnostic. (I personally think this is a good thing.)
I agree with is not syntactically different from and has no reason to be. But I also agree with the fact that the user will probably expect negative numbers to work as literals (even it – syntactically – they're not).
is also supported in literal patterns while arbitrary expressions are not. It'd be reasonable to support it in fragments as well.
Another thing that won't match is a macro call, like , or any of the other macros that I think of as expanding to a literal (, ...).
Code change:
Ok(()) } <del> fn is_legal_fragment_specifier(sess: &ParseSess, features: &Features, attrs: &[ast::Attribute], </del> <ins> fn is_legal_fragment_specifier(_sess: &ParseSess, _features: &Features, _attrs: &[ast::Attribute], </ins> frag_name: &str, <del> frag_span: Span) -> bool { </del> <ins> _frag_span: Span) -> bool { /* * If new fragment specifiers are invented in nightly, `_sess`, * `_features`, `_attrs`, and `_frag_span` will be useful here * for checking against feature gates. See past versions of * this function. */ </ins> match frag_name { "item" | "block" | "stmt" | "expr" | "pat" | "lifetime" | <del> "path" | "ty" | "ident" | "meta" | "tt" | "vis" | "" => true, "literal" => { if !features.macro_literal_matcher && !attr::contains_name(attrs, "allow_internal_unstable") { let explain = feature_gate::EXPLAIN_LITERAL_MATCHER; emit_feature_err(sess, "macro_literal_matcher", frag_span, GateIssue::Language, explain); } true }, </del> <ins> "path" | "ty" | "ident" | "meta" | "tt" | "vis" | "literal" | "" => true, </ins> _ => false, } }

Related discussion:
text: I dunno, maybe this is not such a good idea after all. Re-reading the RFC in a more skeptical light, I felt like the "Motivation" section could use some more concrete use cases. Maybe this is just failure of imagination on my part, though! I think the likelihood of this feature attracting people who really want constant expressions should be acknowledged as a drawback, too.
That's fine IMO. Personally I'd like it to match only explicit literals in code to distinguish, for example, between literal and identifier and produce different code for them. Right now this is not possible because all of , , are too broad and conflict with each other.
Hi All, I have implemented this feature in my fork of Rust over 1.25.0, under this branch: Following a quick review by a rustc mentor I may have the free time to provide a full pull request for this.
BTW label has the tooltip "implemented in nightly and unstable" but I did not see it there, i.e. commits & pull requests referencing this. Did I miss it?
The implementation that I worked on was merged, yay!
Is there anything stopping an FCP for this?
It's currently merged in unstable; do you mean an FCP to declare it stable?
Yes, an FCP to stabilise. Should have clarified.
Currently, it is not possible to pass a literal from a macro to another macro. . I think this is a bug.
Interesting! That is a bug. I opened to track it.
Agreed, this should be allowed just like passing any other node types.
Is there anything else preventing this from being stabilized? The issue above has been fixed.
This has baked for some time now and I believe it should be ready for stabilization. So let's start the review. merge The feature gate test is here: Unstable book: Tests defined here:
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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!
Code change:
Ok(()) } <del> fn is_legal_fragment_specifier(sess: &ParseSess, features: &Features, attrs: &[ast::Attribute], </del> <ins> fn is_legal_fragment_specifier(_sess: &ParseSess, _features: &Features, _attrs: &[ast::Attribute], </ins> frag_name: &str, <del> frag_span: Span) -> bool { </del> <ins> _frag_span: Span) -> bool { /* * If new fragment specifiers are invented in nightly, `_sess`, * `_features`, `_attrs`, and `_frag_span` will be useful here * for checking against feature gates. See past versions of * this function. */ </ins> match frag_name { "item" | "block" | "stmt" | "expr" | "pat" | "lifetime" | <del> "path" | "ty" | "ident" | "meta" | "tt" | "vis" | "" => true, "literal" => { if !features.macro_literal_matcher && !attr::contains_name(attrs, "allow_internal_unstable") { let explain = feature_gate::EXPLAIN_LITERAL_MATCHER; emit_feature_err(sess, "macro_literal_matcher", frag_span, GateIssue::Language, explain); } true }, </del> <ins> "path" | "ty" | "ident" | "meta" | "tt" | "vis" | "literal" | "" => true, </ins> _ => false, } }

Related discussion:
text: A few built-in macros can expand their arguments eagerly through ~m a g i c~, so they accept and likes even if they expect string literals: Fortunately (or not), this currently cannot be done in user-defined macros.
I actually just realised that I can't change it to , as it's used in . So, I've just had to manually unroll the macro. ! It doesn't look pretty. :( Ninja edit: I just tested what actually happens if you try to pass in a non-literal with . It rejects it the exact same way. Does the already make use of this feature? If not, the seems to propagate the required token. Oh, unless the compiler steps in... That's actually probably the case... I've reverted it back to the type.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Since you implemented this, would you be willing to write up the stabilization PR?
sure
This appears to be missing from the Rust reference
Code change:
rustc_data_structures = { path = "../librustc_data_structures" } rustc_hir = { path = "../librustc_hir" } rustc_hir_pretty = { path = "../librustc_hir_pretty" } <del> rustc_parse = { path = "../librustc_parse" } </del> <ins> rustc_lexer = { path = "../librustc_lexer" } </ins> serde_json = "1" rustc_session = { path = "../librustc_session" } rustc_span = { path = "../librustc_span" }

Related discussion:
text: contains a function, which allows to to, well, retokenize existing span: There's only caller of this function: And there's only one caller of that caller: In other words, the only reason why we need is to get the span of hir::Usewhich happens to be a glob import. ( rls needs to know the span of use foo:: with explicit list of imported items" code action. This was the first demoed code action and is still that is implemented ) I'd like to remove the function, as it is one of the few remaining things that requires to be public, and as it is very much a hack anyway. Additionally, I believe I've broken this function accidently a while ago: Rather than retokenizing a span, it retokenized file from the begining until the end of the span (whcih, as uses are usually on top, worked correctly most of the times by accident). What would be the best way to fix this? Add hir::Use-- this seem to be the "proper" solution here Move hack's implementation to where it belongs: in , just fetch the text of the file and look for ('') Remove the deglog functionlity from RLS? I don't like this option as it handicaps the RLS before we formally decided to deprecated it. But I don't completely disregard it either, as, as a whole, it seems to be a full-stack one off hack penetrating every layer of abstraction. WDYT?
I'd suggest the second alternative (move hack's implementation to in librutcsaveanalysis), save analysis is a home of many hacks already and one more until save analysis is deprecated in its entirety won't hurt. Adding span for would be ok if it were useful for anything else at least.
Code change:
<del> Subproject commit 2e951c3ae354bcbd2e50b30798e232949a926b75 </del> <ins> Subproject commit a884d21cc5f0b23a1693d1e872fd8998a4fdd17f </ins>

Related discussion:
text: The AVR-Rust post continues to track AVR-LLVM, which is tracking upstream LLVM. That means we are running into changes from the future LLVM 4.0. I figured we could open up this issue now to track the changes required to stay compatible. This is the current list of upgrade hazards. Note that some of the text may be nonsensical as I don't truly grok all the internals of LLVM so some changes are wild stabs in the dark. It's also possible that some failed fix for earlier problems actually caused later problems: [x] DIDescriptorFlags became a real C++ enum and not a bitset () [x] An EH personality is required for every function that can unwind () [x] pass changed header and constructor name () [x] changed API () [x] Bitcode/ReaderWriter.h has been renamed / API changed () () [x] changed API () [x] changed API () [x] prefers over () [x] string type changes () [x] is not guaranteed to be null terminated () [x] changed return types () [x] Archive support changed error handling types () [x] Teach Rust about an LLVM 4.0 API change for creating debug info for global variables () [x] Check all errors in LLVMRustArchiveIterator API () [x] Upgrade emscripten (kripken/emscripten-fastcomp, kripken/emscripten-fastcomp-clang) [x] Alignment now represented with 32 bits instead of 64 () [x] API changed again () [x] now takes an instead of a and () [x] Symbol lookup error when linking dylibs () [x] Undefined behavior in tests () [x] Unoptimised builds of compilerbuiltins on ARM have references to () A WIP PR that performs the upgrade! Some issues whose resolution is believed to be blocked on LLVM 4.0: [ ]
Next time we do this upgrade we'll need emscripten to do it to. It would be good if we could pull in a working llvm wasm backend in the same upgrade, but that may not be ready before the end of the year.
For the record, I am also working with a fork of LLVM that is tracking upstream (not AVR-LLVM but similar in spirit) and am starting to work on this now.