Show files produced by `--emit foo` in json artifact notifications
Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`.
Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477
Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: https://github.com/hintron/computer-enhance/issues/35
This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files.
Most users won't notice this behavior, to be affected by it all of the following must hold:
- user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything)
- user must specify both `--emit xxx` and `--json artifacts`
- user must refuse to handle unknown artifact types
- user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit #88829 / #89149
The `mir!` macro has multiple parts:
- An optional return type annotation.
- A sequence of zero or more local declarations.
- A mandatory starting anonymous basic block, which is brace-delimited.
- A sequence of zero of more additional named basic blocks.
Some `mir!` invocations use braces with a "block" style, like so:
```
mir! {
let _unit: ();
{
let non_copy = S(42);
let ptr = std::ptr::addr_of_mut!(non_copy);
// Inside `callee`, the first argument and `*ptr` are basically
// aliasing places!
Call(_unit = callee(Move(*ptr), ptr), ReturnTo(after_call), UnwindContinue())
}
after_call = {
Return()
}
}
```
Some invocations use parens with a "block" style, like so:
```
mir!(
let x: [i32; 2];
let one: i32;
{
x = [42, 43];
one = 1;
x = [one, 2];
RET = Move(x);
Return()
}
)
```
And some invocations uses parens with a "tighter" style, like so:
```
mir!({
SetDiscriminant(*b, 0);
Return()
})
```
This last style is generally used for cases where just the mandatory
starting basic block is present. Its braces are placed next to the
parens.
This commit changes all `mir!` invocations to use braces with a "block"
style. Why?
- Consistency is good.
- The contents of the invocation is a block of code, so it's odd to use
parens. They are more normally used for function-like macros.
- Most importantly, the next commit will enable rustfmt for
`tests/mir-opt/`. rustfmt is more aggressive about formatting macros
that use parens than macros that use braces. Without this commit's
changes, rustfmt would break a couple of `mir!` macro invocations that
use braces within `tests/mir-opt` by inserting an extraneous comma.
E.g.:
```
mir!(type RET = (i32, bool);, { // extraneous comma after ';'
RET.0 = 1;
RET.1 = true;
Return()
})
```
Switching those `mir!` invocations to use braces avoids that problem,
resulting in this, which is nicer to read as well as being valid
syntax:
```
mir! {
type RET = (i32, bool);
{
RET.0 = 1;
RET.1 = true;
Return()
}
}
```
Improve compiletest expected/not found formatting
compiletest, oh compiletest, you are truly one of the tools in this repository. You're the omnipresent gatekeeper, ensuring that every new change works, doesn't break the world, and is nice. We thank you for your work, for your tests, for your test runs, for your features that help writing tests, for all the stability and and good you have caused. Without you, Rust wouldn't exist as it does, without you, nothing would work, without you, we would all go insane from having changes break and having to test them all by hand. Thank you, compiletest.
but holy shit i fucking hate your stupid debug output so much i simply cannot take this anymore aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By changing a few magic lines in this file called "runtest.rs", we can cause compiletest to emit nicer messages. This is widely regarded as a good thing. We stop wasting vertical space, allowing more errors to be displayed at once. Additionally, we add colors, which make it so much more pretty *and* gay, both of which are very good and useful.
There's a bit of fuckery needed to get the colors to work. `colored` checks whether stdout is a terminal. We also print to stdout, so that works well.
But.... for some stupid reason that I absolutely refuse to even attempt to debug, stdout is *not* a terminal when executing tests *in a terminal*.
But stderr is >:).
So this just checks whether stderr is a terminal.
If you have a use case where you dump compiletest stdout into a place where colors are not supported while having stderr be a terminal, then I'm sorry for you, but you are gonna get colors and you're gonna like it. Stop it with the usual environment variable, which `colored` also respects by default.
### before (bad, hurts your brain, makes you want to cry)
## after (good, gay, makes you want to cry)
r? jieyouxu said he wants to review the PR
Rollup of 3 pull requests
Successful merges:
- #125311 (Make repr(packed) vectors work with SIMD intrinsics)
- #125849 (Migrate `run-make/emit-named-files` to `rmake.rs`)
- #125851 (Add some more specific checks to the MIR validator)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest, oh compiletest, you are truly one of the tools in this
repository. You're the omnipresent gatekeeper, ensuring that every new
change works, doesn't break the world, and is nice. We thank you for
your work, for your tests, for your test runs, for your features that
help writing tests, for all the stability and and good you have caused.
Without you, Rust wouldn't exist as it does, without you, nothing would
work, without you, we would all go insane from having changes break and
having to test them all by hand. Thank you, compiletest.
but holy shit i fucking hate your stupid debug output so much i simply
cannot take this anymore aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By changing a few magic lines in this file called "runtest.rs", we can
cause compiletest to emit nicer messages. This is widely regarded as a
good thing. We stop wasting vertical space, allowing more errors to be
displayed at once. Additionally, we add colors, which make it so much
more pretty *and* gay, both of which are very good and useful.
There's a bit of fuckery needed to get the colors to work. `colored`
checks whether stdout is a terminal. We also print to stdout, so that
works well.
But.... for some stupid reason that I absolutely refuse to even attempt
to debug, stdout is *not* a terminal when executing tests *in a
terminal*.
But stderr is >:).
So this just checks whether stderr is a terminal.
If you have a use case where you dump compiletest stdout into a place
where colors are not supported while having stderr be a terminal, then
I'm sorry for you, but you are gonna get colors and you're gonna like
it. Stop it with the usual environment variable, which `colored` also
respects by default.
When implementing support for rmake.rs, I copied over the `$TMPDIR`
directory logic from the legacy Makefile setup. In doing so, I also
compiled recipe `rmake.rs` into executables which unfortunately are
placed into `$TMPDIR` as well.
This causes a problem on Windows where:
- The `rmake.exe` executable is placed in `$TMPDIR`.
- We run the `rmake.exe` as a process.
- The process uses `rmake.exe` inside `$TMPDIR`.
- Windows prevents the .exe file from being deleted when the process
is still alive.
- The recipe test code tries to `remove_dir_all($TMPDIR)`, which fails
with access denied because `rmake.exe` is still being used.
We fix this by separating the recipe executable and the sratch
directory:
```
base_dir/
rmake.exe
scratch/
```
We construct a base directory, unique to each run-make test, under
which we place rmake.exe alongside a `scratch/` directory. This
`scratch/` directory is what is passed to rmake.rs tests as `$TMPDIR`,
so now `remove_dir_all($TMPDIR)` has a chance to succeed because
it no longer contains `rmake.exe`.
Oops. This was a fun one to try figure out.
Uplift `{Closure,Coroutine,CoroutineClosure}Args` and friends to `rustc_type_ir`
Part of converting the new solver's `structural_traits.rs` to be interner-agnostic.
I decided against aliasing `ClosureArgs<TyCtxt<'tcx>>` to `ClosureArgs<'tcx>` because it seemed so rare. I could do so if desired, though.
r? lcnr
include missing submodule on bootstrap
As of https://github.com/rust-lang/rust/pull/125408 PR, rustbook now relies on dependencies from the "src/doc/book" submodule.
However, bootstrap does not automatically sync this submodule before reading metadata informations. And if the submodule is not present, reading metadata will fail because rustbook's dependencies will be missing.
This change makes "src/doc/book" to be fetched/synced automatically before trying to read metadata.
cc `@Zalathar`
As of https://github.com/rust-lang/rust/pull/125408 PR,
rustbook now relies on dependencies from the "src/doc/book" submodule.
However, bootstrap does not automatically sync this submodule before reading
metadata informations. And if the submodule is not present, reading
metadata will fail because rustbook's dependencies will be missing.
This change makes "src/doc/book" to be fetched/synced automatically
before trying to read metadata.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
fix diagnostics clearing when flychecks run per-workspace
This might be causing #17300 or it's a different bug with the same functionality.
I wonder if the decision to clear diagnostics should stay in the main loop or maybe the flycheck itself should track it and tell the mainloop?
I have used a hash map but we could just as well use a vector since the IDs are `usizes` in some given range starting at 0. It would be probably faster but this just felt a bit cleaner and it allows us to change the ID to newtype later and we can just use a hasher that returns the underlying integer.
Stabilize `custom_code_classes_in_docs` feature
Fixes#79483.
This feature has been around for quite some time now, I think it's fine to stabilize it now.
## Summary
## 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.
EDIT(camelid): This description is out-of-date. Using `custom,class:language-c` will generate the output `<pre class="language-class:language-c">` as would be expected; it treats `class:language-c` as just the name of a language (similar to the langstring `c` or `js` or what have you) since it does not use the designed class syntax.
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)).
r? `@notriddle`
Update cargo
9 commits in 431db31d0dbeda320caf8ef8535ea48eb3093407..7a6fad0984d28c8330974636972aa296b67c4513
2024-05-28 18:17:31 +0000 to 2024-05-31 22:26:03 +0000
- fix(config): Ensure `--config net.git-fetch-with-cli=true` is respected (rust-lang/cargo#13992)
- Fix libcurl proxy documentation link (rust-lang/cargo#13990)
- fix(new): Dont say were adding to a workspace when a regular package is in root (rust-lang/cargo#13987)
- fix: adjust custom err from cert-check due to libgit2 1.8 change (rust-lang/cargo#13970)
- fix(toml): Ensure targets are in a deterministic order (rust-lang/cargo#13989)
- doc(cargo-package): explain no guarantee of vcs provenance (rust-lang/cargo#13984)
- chore: fix some comments (rust-lang/cargo#13982)
- feat: stabilize `cargo update --precise <yanked>` (rust-lang/cargo#13974)
- Update openssl-src to 111.28.2+1.1.1w (rust-lang/cargo#13976)
r? ghost
Support mdBook preprocessors for TRPL in rustbook
`rust-lang/book` recently added two mdBook preprocessors. Enable `rustbook` to use those preprocessors for books where they are requested by the `book.toml` by adding the preprocessors as path dependencies, and ignoring them where they are not requested, i.e. by all the books other than TRPL at present.
Addresses rust-lang/book#3927
Don't build the `rust-demangler` binary for coverage tests
The coverage-run tests invoke `llvm-cov`, which requires us to specify a command-line demangler that it can use to demangle Rust symbol names.
Historically this used `src/tools/rust-demangler`, which means that we currently build two different command-line tools to help with the coverage tests (`rust-demangler` and `coverage-dump`).
However, it occurred to me that if we add a demangler mode to `coverage-dump` (which is only a handful of lines and no extra dependencies), then we only need to build one helper binary for the coverage tests, and there is no need for tests to build `rust-demangler` at all.
---
Note that the `rust-demangler` binary is separate from the `rustc-demangle` crate (which both `rust-demangler` and `coverage-dump` use as a dependency to do the actual demangling).
---
So the main benefits/motivations here are:
- Slightly faster builds after a fresh checkout or bootstrap bump.
- Making it clear that currently no tests actually need the `rust-demangler` binary, since the coverage tests can use their own tool instead.
coverage: Optionally instrument the RHS of lazy logical operators
(This is an updated version of #124644 and #124402. Fixes #124120.)
When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch.
That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at #124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators.
---
As discussed at https://github.com/rust-lang/rust/issues/124120#issuecomment-2092394586, this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work.
````@rustbot```` label +A-code-coverage
Implement `needs_async_drop` in rustc and optimize async drop glue
This PR expands on #121801 and implements `Ty::needs_async_drop` which works almost exactly the same as `Ty::needs_drop`, which is needed for #123948.
Also made compiler's async drop code to look more like compiler's regular drop code, which enabled me to write an optimization where types which do not use `AsyncDrop` can simply forward async drop glue to `drop_in_place`. This made size of the async block from the [async_drop test](67980dd6fb/tests/ui/async-await/async-drop.rs) to decrease by 12%.
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup
Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.
Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.
---
Old terminology (HIR, rustdoc):
```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
├── `Ty`: (associated) type binding
└── `Const`: associated const equality (constraint)
```
Old terminology (AST, abbrev.):
```
`AssocConstraint`
├── `Bound`
└── `Equality`
├── `Ty`
└── `Const`
```
New terminology (AST, HIR, rustdoc):
```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
├── `Ty`: associated type equality constraint OR associated type binding (for short)
└── `Const`: associated const equality constraint OR associated const binding (for short)
```
r? compiler-errors
compiletest: clarify COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS error
COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS is a confusing name because elsewhere "needs" means "ignore when requirement not met", but here it means "fail when requirement not met".
