| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
move required_consts check to general post-mono-check function
This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants.
Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) https://github.com/rust-lang/rust/issues/115709: ensuring that all locals are dynamically sized.
I didn't expect this to change diagnostics, but it's just cycle errors that change.
r? `@oli-obk`
|
|
|
|
|
|
r=Mark-Simulacrum
ci: actions/checkout@v3 to actions/checkout@v4
- Bump `actions/checkout` from v3 to v4 since v3 uses Node v16 whose support lasts until `11 Sep 2023` [Ref](https://endoflife.date/nodejs)
- https://github.com/actions/checkout/releases/tag/v4.0.0
|
|
get rid of duplicate primitive_docs
Having this duplicate makes editing that file very annoying. And at least locally the generated docs still look perfectly fine...
|
|
:arrow_up: `rust-analyzer`
r? `@ghost`
|
|
|
|
Refactor `opt-dist` to simplify local building
This PR refactors the `opt-dist` tool to make it easier to invoke it locally, outside of CI, and thus simplify building PGO/BOLT optimized `rustc` builds e.g. for distro maintainers. It should also make it easier to run the PGO/BOLT workflow locally e.g. to profile performance or debug issues (looking at you, https://github.com/rust-lang/rust/pull/115554).
|
|
|
|
Do not rename and resign the darwin sanitizers a second time for
macabi.
|
|
The -macabi targets are iOS running on MacOS, and they use the runtime
libraries for MacOS, thus they have the same sanitizers available as the
*-apple-darwin targets.
|
|
|
|
Fix up a few CI images
This forward-ports changes made on the stable branch to fix CI (https://github.com/rust-lang/rust/pull/115787).
|
|
Make AIX known by bootstrap
Use `x.py` to build rustc on AIX directly is failing
```
unknown OS type: AIX
Build completed unsuccessfully in 0:00:00
```
If kernel is `AIX`, we should return default triple `powerpc64-ibm-aix` for current rustc.
|
|
|
|
|
|
|
|
GuillaumeGomez:turn-custom_code_classes_in_docs-into-warning, r=Manishearth
Turn custom code classes in docs into warning
By habit, since it was a new feature gate, I added a check which emitted an error in case the new syntax was used. However, since rustdoc tags parser was accepting *everything*, using the "new" syntax should never ever emit errors. It now emits a warning.
Follow-up of #110800.
cc `@Manishearth`
r? `@notriddle`
|
|
Co-authored-by: Michael Howell <michael@notriddle.com>
|
|
|
|
when its syntax is used.
|
|
Stabilize the `Saturating` type
Closes #87920
Closes #92354
Stabilization report https://github.com/rust-lang/rust/issues/87920#issuecomment-1652346124
FCP https://github.com/rust-lang/rust/issues/87920#issuecomment-1676438885
|
|
r=albertlarsan68
optimize and cleanup bootstrap source
I suggest reviewing this commit by commit.
|
|
According to 4198fac7390509128c42757fcfb89a0effde4a8e, italic fonts are
not preloaded because they're rarely used, but bold fonts are. This
seems to be true of bold Source Code Pro and bold Fira Sans, but
bold and italic Source Serif Pro seem to be equally heavily used.
This is, I assume, the result of using Fira Sans Bold and Source Code
Bold headings, so you only get bold Serif text when the doc author
uses strong `**` emphasis (or within certain kinds of tooltip,
which shouldn't be preloaded because they only show up long after
the page is loaded).
To check this, run these two commands in the browser console to
measure how much they're used. The measurement is extremely rough,
but it gets the idea across: the two styles are about equally popular.
// count bold elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontWeight > 400 }).length
// count italic elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontStyle == "italic" }).length
| URL | Bold | Italic |
|---------|-----:|-------:|
| [std] | 2 | 9 |
| [Vec] | 8 | 89 |
| [regex] | 33 | 17 |
[std]: https://doc.rust-lang.org/nightly/std/index.html
[Vec]: https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html
[regex]: https://docs.rs/regex/1.9.5/regex/index.html
|
|
Overall optimizations for bootstrap on conditions, assertions,
trait implementations, etc.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
The 22.10 Ubuntu repositories were returning 404s in last stable build.
|
|
r=compiler-errors
update rust_analyzer_settings.json
This works around https://github.com/rust-lang/rust-analyzer/issues/15595, and avoids relying on the unspecified working directory of this command.
|
|
Not really a saving in terms of lines of code, but at least the logic is de-duplicated
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Accept additional user-defined syntax classes in fenced code blocks
Part of #79483.
This is a re-opening of https://github.com/rust-lang/rust/pull/79454 after a big update/cleanup. I also converted the syntax to pandoc as suggested by `@notriddle:` the idea is to be as compatible as possible with the existing instead of having our own syntax.
## Motivation
From the original issue: https://github.com/rust-lang/rust/issues/78917
> The technique used by `inline-c-rs` can be ported to other languages. It's just super fun to see C code inside Rust documentation that is also tested by `cargo doc`. I'm sure this technique can be used by other languages in the future.
Having custom CSS classes for syntax highlighting will allow tools like `highlight.js` to be used in order to provide highlighting for languages other than Rust while not increasing technical burden on rustdoc.
## What is the feature about?
In short, this PR changes two things, both related to codeblocks in doc comments in Rust documentation:
* Allow to disable generation of `language-*` CSS classes with the `custom` attribute.
* Add your own CSS classes to a code block so that you can use other tools to highlight them.
#### The `custom` attribute
Let's start with the new `custom` attribute: it will disable the generation of the `language-*` CSS class on the generated HTML code block. For example:
```rust
/// ```custom,c
/// int main(void) {
/// return 0;
/// }
/// ```
```
The generated HTML code block will not have `class="language-c"` because the `custom` attribute has been set. The `custom` attribute becomes especially useful with the other thing added by this feature: adding your own CSS classes.
#### Adding your own CSS classes
The second part of this feature is to allow users to add CSS classes themselves so that they can then add a JS library which will do it (like `highlight.js` or `prism.js`), allowing to support highlighting for other languages than Rust without increasing burden on rustdoc. To disable the automatic `language-*` CSS class generation, you need to use the `custom` attribute as well.
This allow users to write the following:
```rust
/// Some code block with `{class=language-c}` as the language string.
///
/// ```custom,{class=language-c}
/// int main(void) {
/// return 0;
/// }
/// ```
fn main() {}
```
This will notably produce the following HTML:
```html
<pre class="language-c">
int main(void) {
return 0;
}</pre>
```
Instead of:
```html
<pre class="rust rust-example-rendered">
<span class="ident">int</span> <span class="ident">main</span>(<span class="ident">void</span>) {
<span class="kw">return</span> <span class="number">0</span>;
}
</pre>
```
To be noted, we could have written `{.language-c}` to achieve the same result. `.` and `class=` have the same effect.
One last syntax point: content between parens (`(like this)`) is now considered as comment and is not taken into account at all.
In addition to this, I added an `unknown` field into `LangString` (the parsed code block "attribute") because of cases like this:
```rust
/// ```custom,class:language-c
/// main;
/// ```
pub fn foo() {}
```
Without this `unknown` field, it would generate in the DOM: `<pre class="language-class:language-c language-c">`, which is quite bad. So instead, it now stores all unknown tags into the `unknown` field and use the first one as "language". So in this case, since there is no unknown tag, it'll simply generate `<pre class="language-c">`. I added tests to cover this.
Finally, I added a parser for the codeblock attributes to make it much easier to maintain. It'll be pretty easy to extend.
As to why this syntax for adding attributes was picked: it's [Pandoc's syntax](https://pandoc.org/MANUAL.html#extension-fenced_code_attributes). Even if it seems clunkier in some cases, it's extensible, and most third-party Markdown renderers are smart enough to ignore Pandoc's brace-delimited attributes (from [this comment](https://github.com/rust-lang/rust/pull/110800#issuecomment-1522044456)).
## Raised concerns
#### It's not obvious when the `language-*` attribute generation will be added or not.
It is added by default. If you want to disable it, you will need to use the `custom` attribute.
#### Why not using HTML in markdown directly then?
Code examples in most languages are likely to contain `<`, `>`, `&` and `"` characters. These characters [require escaping](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pre) when written inside the `<pre>` element. Using the \`\`\` code blocks allows rustdoc to take care of escaping, which means doc authors can paste code samples directly without manually converting them to HTML.
cc `@poliorcetics`
r? `@notriddle`
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
r=GuillaumeGomez
rustdoc: merge theme css into rustdoc.css
Based on https://github.com/rust-lang/rust/pull/115812#issuecomment-1717960119
Having them in separate files used to make more sense, before the migration to CSS variables made the theme files as small as they are nowadays. This is already how docs.rs and mdBook do it.
WebPageTest comparison page:
https://www.webpagetest.org/video/compare.php?tests=230913_AiDc3F_B9E,230913_AiDc7G_B9B
Filmstrip comparison:
Old waterfall:
New waterfall:
|
|
|
|
|
|
|
|
|
|
From<&std::string::String>` is not satisfied"
|
|
|
|
|
|
|
