jiebi/CodeConvo huggingface dataset:
Code change:
--codeblock-error-color: rgba(255, 0, 0, .5); --codeblock-ignore-hover-color: rgb(255, 142, 0); --codeblock-ignore-color: rgba(255, 142, 0, .6); <ins> --warning-border-color: rgb(255, 142, 0); </ins> --type-link-color: #ffa0a5; --trait-link-color: #39afd7; --assoc-item-link-color: #39afd7;

Related discussion:
text: I am uncertain if this is any better than what suggested from the GitHub syntax, but because of the similarity to the doc intra-link syntax. I do feel like this might be interesting because it should go well with backwards compatibility. However, this may look worse than the GitHub syntax solution when not going through cargo doc.
I thought I'd already left this comment, but I'd really like to avoid adding more markdown syntax where possible. This feature works fine without special syntax, I don't think we need it. edit: copying over the reasoning from the :
Although, I might not agree fully, I can fully appreciate and understand the reasoning you left in the corresponding PR. Still, I do think it might be worth to standardize some kind of syntax for some kind of warning block. This does not actually require customized markdown. Alternatively, I can suggest adding the GitHub flavor with emojis to the . This may help in standardizing short form warnings and notes within documentation. We could for example propose to standardize: which should look like the following I do value people's opinion on this. Is this a possible compromise?
That's a valid alternative, I think the yellow color is pretty important though, and it's useful for themes to be able to make styling decisions about warnings so I do think that having some way of marking it is important. I just don't think the way of marking it should be some magic invocation as opposed to CSS classes. (And I think that the bar for a feature that is adding new semantics to the Rustdoc markdown parser is much, much higher than that of one stabilizing a CSS class)
100% agree. I will look at the Rust API guidelines issue and possibly an RFC to rust to track the adoption in GitHub and possibly eventually merge. Thank you :smile:
Beyond all this discussion of third-party tools, I'd really like to make sure that whatever new syntax and presentation we add to rustdoc can also be to [mdBook]. That way, when the standard library starts using callouts, we can make sure the same style also gets used in The Book. Mostly, The Book seems to just use blockquotes, often with headings like [this one about ownership]. mdBook doesn't do anything special with it: it's [just a block quote with a header].
Code change:
--codeblock-error-color: rgba(255, 0, 0, .5); --codeblock-ignore-hover-color: rgb(255, 142, 0); --codeblock-ignore-color: rgba(255, 142, 0, .6); <ins> --warning-border-color: rgb(255, 142, 0); </ins> --type-link-color: #ffa0a5; --trait-link-color: #39afd7; --assoc-item-link-color: #39afd7;

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:
--codeblock-error-color: rgba(255, 0, 0, .5); --codeblock-ignore-hover-color: rgb(255, 142, 0); --codeblock-ignore-color: rgba(255, 142, 0, .6); <ins> --warning-border-color: rgb(255, 142, 0); </ins> --type-link-color: #ffa0a5; --trait-link-color: #39afd7; --assoc-item-link-color: #39afd7;

Related discussion:
text: It doesn't hurt to have it and if it can helps users, well, why not doing it. :)
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. #![feature(box_syntax)] struct Node<T: ?Sized>(T); fn main() { let x: Box<Node<[isize]>> = box Node([]); } </ins>

Related discussion:
text: seems to result in a call to in the drop glue (and no allocates), which results in a crash. Just doing works, as do non-empty input arrays.
cc
cc should this have been fixed by ? Or did cause a regression?
it appears to have been fixed, this example doesn't crash in my local branch (assuming it's not something else I've done since).
I have 2 tests based on example, one using the syntax and one using . Interestingly, using causes a compile time error: Shouldn't they both behave similar in this case?
test with doesn't compile because the argument to that function must be . However, the code does compile and run successfully with the syntax, so a PR containing src/test/run-pass/issue- from should close this issue.
Code change:
/// Whether the original and suggested code are visually similar enough to warrant extra wording. pub fn is_case_difference(sm: &SourceMap, suggested: &str, sp: Span) -> bool { // FIXME: this should probably be extended to also account for `FO0` → `FOO` and unicode. <del> let found = sm.span_to_snippet(sp).unwrap(); </del> <ins> let found = match sm.span_to_snippet(sp) { Ok(snippet) => snippet, Err(e) => { warn!("Invalid span {:?}. Err={:?}", sp, e); return false; } }; </ins> let ascii_confusables = &['c', 'f', 'i', 'k', 'o', 's', 'u', 'v', 'w', 'x', 'y', 'z']; // All the chars that differ in capitalization are confusable (above): let confusable = found

Related discussion:
text: Steps to replicate: two files and in the same directory with the following content: both files the following error I note that the looks quite suspicious, since there are fewer than bytes in the source text. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Full trace:
there's a single in . You can just return if the output of is .
Are you sure that's correct? I was looking at the invalid that begins in the source file and ends in a separate virtual file. It seems like it should always be an error to record a into the such that is false. And perhaps if this were corrected, the would succeed.
That is a correct assessment, but the current state is that whenever we involve macros we can easily generate incorrect s. We shouldn't, but fixing that underlying issue is much harder than just dealing with the fallout. We have some efforts to clean up the situation around (and its gotten much better lately), but there are cases like for suggestions where we are assembling new spans from different sources and checking at generation time that they are valid would become too verbose and hide the actual logic. For now, I would just fix the stray and fix the ICE so that we can buy time.
A compiler built from that pull request no longer exhibits an ICE on this example.
Thanks for fixing it!
Code change:
<ins> error[E0262]: invalid lifetime parameter name: `'static` --> $DIR/generic_const_early_param.rs:4:20 | LL | struct DataWrapper<'static> { |                    ^^^^^^^ 'static is a reserved lifetime name error[E0261]: use of undeclared lifetime name `'a` --> $DIR/generic_const_early_param.rs:6:12 | LL | struct DataWrapper<'static> { |                    - help: consider introducing lifetime `'a` here: `'a,` LL | LL |     data: &'a [u8; Self::SIZE], |            ^^ undeclared lifetime error[E0261]: use of undeclared lifetime name `'a` --> $DIR/generic_const_early_param.rs:11:18 | LL | impl DataWrapper<'a> { |     -            ^^ undeclared lifetime |     | |     help: consider introducing lifetime `'a` here: `<'a>` warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/generic_const_early_param.rs:1:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default error: lifetime may not live long enough --> $DIR/generic_const_early_param.rs:6:20 | LL |     data: &'a [u8; Self::SIZE], |                    ^^^^^^^^^^ requires that `'_` must outlive `'static` error: aborting due to 4 previous errors; 1 warning emitted Some errors have detailed explanations: E0261, E0262. For more information about an error, try `rustc --explain E0261`. </ins>

Related discussion:
text: <!-- ICE: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-08 found 7 bors merge commits in the specified range commit[0] 2022-06-06: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2022-06-06: Auto merge of - matthiaskrgr:rollup-ajyvjd3, r=matthiaskrgr commit[2] 2022-06-07: Auto merge of - RalfJung:miri, r=RalfJung commit[3] 2022-06-07: Auto merge of - jackh726:remove-borrowck-mode, r=nikomatsakis commit[4] 2022-06-07: Auto merge of - scottmcm:add-coldcc, r=nagisa,lcnr commit[5] 2022-06-07: Auto merge of - Dylan-DPC:rollup-ya51k1k, r=Dylan-DPC commit[6] 2022-06-07: Auto merge of - Dylan-DPC:rollup-0ae3pwp, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days
I guess? :thinking:
Code change:
<ins> error: expected item, found `;` --> $DIR/fn-no-semicolon-issue-124935-semi-after-item.rs:5:1 | LL | ; | ^ help: remove this semicolon error: aborting due to 1 previous error </ins>

Related discussion:
text: Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.
Code change:
return Some(p); } if let Some(e) = self.expr { <del> if let ast::ExprKind::Lit(_) = e.kind { </del> <ins> if matches!(e.kind, ast::ExprKind::Lit(_) | ast::ExprKind::IncludedBytes(_)) { </ins> return Some(P(ast::Pat { id: ast::DUMMY_NODE_ID, span: e.span,

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: code compiles and execute Instead, this happened: compilation fails with It most recently worked on: and <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --used by . I suspect (but did not confirm) might be the cause of the breakage as it is a recent change on that area. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
The code posted has a missing delimiter.
oops, fixed
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten

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.
Code change:
COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten

Related discussion:
text: I'm looking through the AVR-Rust commits and I'd love to coordinate --- feel free to ping me on IRC () or via mail!
Note that there is a regression reported against llvm 4.0 regarding the powi intrinsic on armhf targets: I'm explicitly mentioning this here, because there were previously problems with it, see and related issues. Also cc rust-lang-nursery/compiler-builtins, an issue about the same problem in the compiler-rt rust port.
To clarify what I think the is referring to (correct me if I'm wrong) In LLVM 3.9 and before, the calling convention LLVM used with the powidf2 and powisf2 intrinsics was basically the C calling convention In LLVM 4.0, the backend was corrected to expect these intrinsics to have the aapcs calling convention One person that aapcs is expected for powis2f and powid2f, while another a claiming that the normal C calling convention should be used. So it seems that if the LLVM change is not reverted (expected powisf2 to be aapcs) then we need to update our definition. This is going to be a huge PITA for supporting multiple LLVM versions as well. We need to select the calling convention depending on the LLVM version as well...
Any objections to doing that coordination here on GitHub, or on one of our forks?
I don't have strong preferences for the communication channel.
should address what is listed as API changes" above (the core of the change is in how attributes are represented).
I would prefer to upstream LLVM 4.0 compatibility patches sooner rather than later. That includes my own work obviously, but I'm also looking at the commits I cherry-picked from AVR-Rust. In particular, looks like a reasonable simplification even independent of LLVM 4.0 compatibility, and looks like a nice little self-contained fix. Could you create PRs for those? (If you don't have the time but are otherwise fine with upstreaming, I'd be happy to manage that, giving proper credit of course.)
Absolutely! I wasn't really sure how much we could expect LLVM 4 to change as it goes towards stable / how much churn the Rust maintainers would want to put up with. I'll get those pulled out and submitted soon. I think I'm also starting to understand some of the silly error handling that the new LLVM does.
Code change:
COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten

Related discussion:
text: Awesome, thanks in advance!
BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of
Does anyone have ETA? I'd like to know when I can use AVR. :)
You should follow along at avr-rust/rust for the AVR-specific issues. Upgrading to LLVM 4 will not magically yield AVR support.
Ok, thank you!
I've created for the API change.
I've also created for another debug info API change.
After putting all of those patches on top of master, was successfully built. I got several undefined references, most likely due to my local LLVM setup.
I think the next step after all those patches land is to allow LLVM 4.0 in the configure/rustbuild scripts and then actually update the submodule.
We'll also need to fix that AAPCS bug first, I just noticed it
Don't forget : I think that means that the Rust fork of LLVM is following the Emscripten fork of LLVM, thus Emscripten needs to upgrade to LLVM 4.0 / master before Rust can.
And I'm hoping to supersede it with
I just ran into which changed the alignment from u64 to u32. Will think about a proper fix later, unless someone beats me to it (but should merge first to avoid further conflicts).
And it says So, that will be "exciting".
Is there much left blocking an upgrade?
This: Has to be done too but I don't know if it's currently being worked on. Any info on that ^?
No nobody is actively working on an emscripten upgrade. Since even when that is done it will probably take a lot of work to land an LLVM upgrade, there's probably more we can do to prepare. Once we decide we want to do it, somebody can prepare a patch to throw at the bots. It seems likely stuff will not work and it will be a slog to fix it all, which will give us time. We don't need emcc to generate wasm stds, just a fairly small patch on our LLVM branch that will hopefully port without much difficulty. So if somebody feels motivated, it's not too soon to start going after it. As to the emscripten upgrade, we should at least let know that we're starting to think seriously about doing the upgrade, and need emscripten to upgrade LLVM too.