jiebi/CodeConvo huggingface dataset:
Code change:
font-size: 1.25rem; } <ins> /* This class only exists for users who want to draw attention to a particular element in their documentation. */ .content .docblock .warning { border-left: 2px solid var(--warning-border-color); padding: 14px; position: relative; /* The "!important" part is required because the rule is otherwise overruled in this CSS selector: ".docblock > :not(.more-examples-toggle):not(.example-wrap)" */ overflow-x: visible !important; } .content .docblock .warning::before { color: var(--warning-border-color); content: "ⓘ"; position: absolute; left: -25px; top: 5px; font-weight: bold; font-size: 1.25rem; } </ins> a.test-arrow { visibility: hidden; position: absolute;

Related discussion:
text: [mdBook]: [this one about ownership]: [just a block quote with a header]:
This is a good point. Once we have something merged here, I'll send a PR there to have an equivalent.
CC
I'd be happy to add some CSS rules to mdbook if that is what you are proposing.
Yeah, it is.
FYI, using a is not semantic and Microsoft GitHub is setting a bad precedence. — CommonMark Spec v0.30, denotes a in Markdown and is rendered as such. — W3C HTML spec, Unless you are quoting a source, this is not the correct element to use. While I disagree with even using altogether, at least some tools out there are at least translating the blockquote in admonition context into a (div has no semantic meaning which is unfortunately the best HTML option for admonitions). It would be ill-advised to follow Microsoft GitHub’s Markdown syntax fork&mdash;especially with their disregard for semantics. Similarly using a block would also be breaking semantics as an admonition is not preformatted text. CommonMark does have that could be used if the solution was preferred. There’s also other reasonable options noted here that don’t break semantics.
I agree that block quotes for callouts are bad, and would like to work with mdBook to roll out a common syntax (probably ) that will replace the ad-hoc, unsemantic markup that they use right now.
Using is what we agreed upon in The debate now is on the look itself.
Unfortunately isn't great because markdown has a "boundary" when HTML tags are used. I wanted to add a warning indicating that users probably wanted another trait, but intra-doc links don't work (which is the correct behavior per markdown spec).
Works perfectly fine though (well, minus the UI bug I just discovered haha): ! I used this code: I'll send a PR to improve documentation.
Ah. Well I suppose the issue wasn't with intra-doc links, but with inline code blocks. What I tried was that but with bar`, and it failed.
Works too: !
I opened which adds extra explanation on how to use markdown inside html tags. That should solve your issue.
That note is exactly what I was just looking in to. I had it inline, given my familiarity with HTML. TIL that matters.
Code change:
font-size: 1.25rem; } <ins> /* This class only exists for users who want to draw attention to a particular element in their documentation. */ .content .docblock .warning { border-left: 2px solid var(--warning-border-color); padding: 14px; position: relative; /* The "!important" part is required because the rule is otherwise overruled in this CSS selector: ".docblock > :not(.more-examples-toggle):not(.example-wrap)" */ overflow-x: visible !important; } .content .docblock .warning::before { color: var(--warning-border-color); content: "ⓘ"; position: absolute; left: -25px; top: 5px; font-weight: bold; font-size: 1.25rem; } </ins> a.test-arrow { visibility: hidden; position: absolute;

Related discussion:
text: It doesn't hurt to have it and if it can helps users, well, why not doing it. :)
Code change:
use ext::tt::macro_parser::{parse, parse_failure_msg}; use ext::tt::quoted; use ext::tt::transcribe::transcribe; <del> use feature_gate::{self, emit_feature_err, Features, GateIssue}; </del> <ins> use feature_gate::Features; </ins> use parse::{Directory, ParseSess}; use parse::parser::Parser; use parse::token::{self, NtTT};

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:
use ext::tt::macro_parser::{parse, parse_failure_msg}; use ext::tt::quoted; use ext::tt::transcribe::transcribe; <del> use feature_gate::{self, emit_feature_err, Features, GateIssue}; </del> <ins> use feature_gate::Features; </ins> use parse::{Directory, ParseSess}; use parse::parser::Parser; use parse::token::{self, NtTT};

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:
use ext::tt::macro_parser::{parse, parse_failure_msg}; use ext::tt::quoted; use ext::tt::transcribe::transcribe; <del> use feature_gate::{self, emit_feature_err, Features, GateIssue}; </del> <ins> use feature_gate::Features; </ins> use parse::{Directory, ParseSess}; use parse::parser::Parser; use parse::token::{self, NtTT};

Related discussion:
text: See for info about what commands tagged team members can give me.
Reading through the tests, I see that is a literal. While that makes sense to me, I remember hearing that it wasn't, but was instead a negation operator and a literal. Am I misremembering?
cc on
I agree that it makes sense. I would say that even if is interpreted as negation + a literal, I would probably still want the macro matcher to accept since that behavior seems more intuitive. In other words, I would see being more as an implementation detail than what a literal is in the mental model.
I think that the nuance with causes a bit of a problem, because I don't think it should be treated as a literal, but I also don't think that the current implementation of would allow detecting it either. You could naïvely allow but that would allow which is clearly wrong.
there are tests currently implemented that verify that is detected as a literal.
I worded that wrong; I meant that only having a matcher and not being able to distinguish strings and numbers means that you can't easily make not a literal.
for procedural macros the input as lexed by the compiler is (two tokens) but procedural macros can create tokens that are negatives (like ). In that sense matching for makes sense to me.
Are literals generated by the compiler counted as true literals? A quick example would be something like: This fails to match, as the expansion, I guess, happens after the selection. I just naively assumed that would have worked.
is not a literal generated by the compiler, it is an identifier followed by an exclamation mark followed by a set of parentheses containing some tokens. See for example: If you were to use it in expression position, it would be interpreted as an invocation of which expands to a string literal. In this case and in your macro though, it is never in a syntactic position where it would be treated as an expression.
I can understand semantically why it doesn't make sense, I just thought it would have, but that being said, I already changed it to , so there's no issue. It just made more sense to me as a literal, because according to the compiler, it could generate a literal from it. I guess it was more a question than an actual issue.
This is true, but there's more to it!
Code change:
use ext::tt::macro_parser::{parse, parse_failure_msg}; use ext::tt::quoted; use ext::tt::transcribe::transcribe; <del> use feature_gate::{self, emit_feature_err, Features, GateIssue}; </del> <ins> use feature_gate::Features; </ins> use parse::{Directory, ParseSess}; use parse::parser::Parser; use parse::token::{self, NtTT};

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:
<ins> #![feature(staged_api)] #![stable(feature = "libfoo", since = "1.0.0")] #[unstable(feature = "foo", reason = "...", issue = "none")] pub fn foo() {} #[stable(feature = "libfoo", since = "1.0.0")] pub struct Foo; impl Foo { #[unstable(feature = "foo", reason = "...", issue = "none")] pub fn foo(&self) {} } </ins>

Related discussion:
text: It would be more helpful to suggest the method for the typo rather than a nightly-only symbol which isn't actually available. the suggestion doesn't work. method is actually available on a . method has been stable since 1.0.0. had trouble noticing the difference between and and could have used the compiler's help. No response Reproduced with 1.68.0 stable and 1.70 nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Code change:
span } = *self; <del> hcx.hash_hir_item_like(attrs, |hcx| { </del> <ins> hcx.hash_hir_item_like(attrs, is_const, |hcx| { </ins> hcx.while_hashing_spans(hash_spans, |hcx| { name.hash_stable(hcx, hasher); attrs.hash_stable(hcx, hasher);

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
was_remapped, Some(&unmapped_path)); <del> return match self.source_file_by_stable_id(file_id) { </del> <ins> let lrc_sf = match self.source_file_by_stable_id(file_id) { </ins> Some(lrc_sf) => lrc_sf, None => { let source_file = Lrc::new(SourceFile::new(

Related discussion:
text: I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened
Code change:
source_file: Lrc<rustc_span::SourceFile>, override_span: Option<Span>, ) -> Self { <del> // Make sure external source is loaded first, before accessing it. // While this can't show up during normal parsing, `retokenize` may // be called with a source file from an external crate. sess.source_map().ensure_source_file_source_present(Lrc::clone(&source_file)); let src = if let Some(src) = &source_file.src { Lrc::clone(&src) } else if let Some(src) = source_file.external_src.borrow().get_source() { Lrc::clone(&src) } else { </del> <ins> let src = source_file.src.clone().unwrap_or_else(|| { </ins> sess.span_diagnostic .bug(&format!("cannot lex `source_file` without source: {}", source_file.name)); <del> }; </del> <ins> }); </ins> StringReader { sess,

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:
) => { eq_closure_binder(lb, rb) && lc == rc <del> && la.map_or(false, CoroutineKind::is_async) == ra.map_or(false, CoroutineKind::is_async) </del> <ins> && eq_coroutine_kind(*la, *ra) </ins> && lm == rm && eq_fn_decl(lf, rf) && eq_expr(le, re)

Related discussion:
text: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly
Code change:
impl Foo { // @has async_fn/struct.Foo.html <del> // @has - '//*[@class="method"]' 'pub async fn complicated_lifetimes( &self, context: &impl Bar ) -> impl Iterator<Item = &usize>' </del> <ins> // @has - '//*[@class="method"]' 'pub async fn complicated_lifetimes( &self, context: &impl Bar, ) -> impl Iterator<Item = &usize>' </ins> pub async fn complicated_lifetimes(&self, context: &impl Bar) -> impl Iterator<Item = &usize> { [0].iter() }

Related discussion:
text: Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
with_interner(|interner| interner.gensymed(self)) } <ins> pub fn is_gensymed(self) -> bool { with_interner(|interner| interner.is_gensymed(self)) } </ins> pub fn as_str(self) -> LocalInternedString { with_interner(|interner| unsafe { LocalInternedString {

Related discussion:
text: The error happens on latest stable and nightly. Steps to reproduce: ; : : returns error: The error only happens if the module is named (for instance, and work without error). The error is not produced if doesn't use in any way. If doesn't contain imports but uses the library directly (e.g. ), the error is produced. always succeeds. I don't know if this is supposed to be forbidden but the error message seems to be misleading.
The second instance is injected implicitly. The error could be better, yes.
Where exactly is injected - in the library or in the test? Why does the library work on its own? Why does conflict with in the test?
Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue. is injected into both the library and the test, but only the first one causes the error. If you set in , then you'll see the error immediately while compiling - conflicts with . On 2018 edition, however, is injected in more subtle way, as where is some unique symbol that still has the string representation , but doesn't clash with anything in the same crate. Unfortunately, turns into "just " after encoding into metadata in the compiled library (this is the bug). So, when we load that library from the test it looks like the library defines two conflicting items.
The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected specifically from being encoded (it doesn't really need to be encoded).
Fixed in
Code change:
if let Res::Def(DefKind::Mod, ..) = child.res { self.resolve_doc_links_extern_inner(def_id); // Inner attribute scope } <del> // Traits are processed in `add_extern_traits_in_scope`. </del> <ins> // `DefKind::Trait`s are processed in `process_extern_impls`. </ins> if let Res::Def(DefKind::Mod | DefKind::Enum, ..) = child.res { self.process_module_children_or_reexports(def_id); } <ins> if let Res::Def(DefKind::Struct | DefKind::Union | DefKind::Variant, _) = child.res { let field_def_ids = Vec::from_iter( self.resolver .cstore() .associated_item_def_ids_untracked(def_id, self.sess), ); for field_def_id in field_def_ids { self.resolve_doc_links_extern_outer(field_def_id, scope_id); } } </ins> } } }

Related discussion:
text: Here is a complete (minimized) reproducer: It can be reproduced with a workspace with two crates "a" and "b" where: The crate "a" depends on the public () crate and its code is: . The crate "b" depends on the workspace crate and its code is: With that setup, the command rightfully succeeds using the stable toolchain. But fails when using the latest (2022-04-25) nightly toolchain. The bug is observable on nightly only (works fine on stable, and beta) : <details<summary<strongBacktrace</strong</summary<p</p</details
Fixed in
Code change:
self.report_error_if_loan_conflicts_with_restriction( old_loan, new_loan, old_loan, new_loan) && self.report_error_if_loan_conflicts_with_restriction( <del> new_loan, old_loan, old_loan, new_loan); </del> <ins> new_loan, old_loan, old_loan, new_loan) </ins> } pub fn report_error_if_loan_conflicts_with_restriction(&self,

Related discussion:
text: Ran into this when running a fauly tt muncher with ~100 items. We can now compete with C++ in the compiler spew area as well! :-P
Ran into this while demonstrating why you need raw pointers to do a singly-linked-queue: 66 Borrow check errors in this test.