Update books
## rust-lang/book
6 commits in 85442a608426d3667f1c9458ad457b241a36b569..5228bfac8267ad24659a81b92ec5417976b5edbc
2024-05-29 20:55:49 UTC to 2024-05-27 17:22:03 UTC
- Fix typo in ch10-03 (rust-lang/book#3539)
- Backport changes to ch 9 and 10 (rust-lang/book#3946)
- infra: correctly support preprocessors for nostarch (rust-lang/book#3944)
- Use `<kbd>` instead of `<span class="keystroke">` (rust-lang/book#3945)
- infra: Fix clippy warning in remove_markup (rust-lang/book#3943)
- fix: ch10-03 - misleading use of expect on .split (rust-lang/book#3939)
## rust-lang/edition-guide
2 commits in 0c68e90acaae5a611f8f5098a3c2980de9845ab2..bbaabbe088e21a81a0d9ae6757705020d5d7b416
2024-05-24 19:07:18 UTC to 2024-05-21 22:40:52 UTC
- 2024: Document reserving `gen` keyword (rust-lang/edition-guide#300)
- 2024: Document cargo changes (rust-lang/edition-guide#301)
## rust-embedded/book
1 commits in dd962bb82865a5284f2404e5234f1e3222b9c022..b10c6acaf0f43481f6600e95d4b5013446e29f7a
2024-05-31 08:51:50 UTC to 2024-05-31 08:51:50 UTC
- Add some explanations as to why exception re-entrancy may still be an issue in a multicore-environment. (rust-embedded/book#367)
## rust-lang/reference
6 commits in e356977fceaa8591c762312d8d446769166d4b3e..6019b76f5b28938565b251bbba0bf5cc5c43d863
2024-06-03 15:58:57 UTC to 2024-05-25 18:35:54 UTC
- Add Apple `target_abi` values to the example values (rust-lang/reference#1507)
- this needs a space (rust-lang/reference#1506)
- Mention Variadics With No Fixed Parameter (rust-lang/reference#1494)
- Add "scopes" chapter. (rust-lang/reference#1040)
- update patterns.md for const pattern RFC (rust-lang/reference#1456)
- document guarantee about evaluation of associated consts and const blocks (rust-lang/reference#1497)
## rust-lang/rust-by-example
3 commits in 20482893d1a502df72f76762c97aed88854cdf81..4840dca06cadf48b305d3ce0aeafde7f80933f80
2024-05-28 13:56:12 UTC to 2024-05-27 11:51:10 UTC
- Update mdbook-i18n-helpers to 0.3.3 (rust-lang/rust-by-example#1857)
- Fix CI failure (rust-lang/rust-by-example#1856)
- Add precision on From/Into asymmetry to from_into.md (rust-lang/rust-by-example#1855)
## rust-lang/rustc-dev-guide
4 commits in b6d4a4940bab85cc91eec70cc2e3096dd48da62d..6a7374bd87cbac0f8be4fd4877d8186d9c313985
2024-05-31 00:27:28 UTC to 2024-05-21 09:56:12 UTC
- Flesh out the "representing types" chapter (rust-lang/rustc-dev-guide#1985)
- sync the stage0 filename (rust-lang/rustc-dev-guide#1979)
- Add Rust for Linux notification group entry (rust-lang/rustc-dev-guide#1984)
- fix some typos (rust-lang/rustc-dev-guide#1983)
Handle no values cfgs with `--print=check-cfg`
This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values.
The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value.
So for `cfg(feature, values())` we would print `feature=`.
I also added the missing tracking issue number in the doc.
r? ```@petrochenkov```
Align `Term` methods with `GenericArg` methods, add `Term::expect_*`
* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.
I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.
r? types
ARM Target Docs Update
Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents.
Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.
Add tracking issue and unstable book page for `"vectorcall"` ABI
Originally added in 2015 by #30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now.
Tracking issue: #124485
Some of the bootstrap logics should be ignored during unit tests because they either
make the tests take longer or cause them to fail. Therefore we need to be able to exclude
them from the bootstrap when it's called by unit tests. This change introduces a new feature
called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows
us to keep the logic separate between compiler builds and bootstrap tests without needing messy
workarounds (like checking if target names match those in the unit tests).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Make `WHERE_CLAUSES_OBJECT_SAFETY` a regular object safety violation
#### The issue
In #50781, we have known about unsound `where` clauses in function arguments:
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible;
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
// `where` clause satisfied for the object, meaning that the function now *looks* callable.
impl Impossible for dyn Foo {}
fn main() {
let x: &dyn Foo = &&();
x.impossible();
}
```
... which currently segfaults at runtime because we try to call a method in the vtable that doesn't exist. :(
#### What did u change
This PR removes the `WHERE_CLAUSES_OBJECT_SAFETY` lint and instead makes it a regular object safety violation. I choose to make this into a hard error immediately rather than a `deny` because of the time that has passed since this lint was authored, and the single (1) regression (see below).
That means that it's OK to mention `where Self: Trait` where clauses in your trait, but making such a trait into a `dyn Trait` object will report an object safety violation just like `where Self: Sized`, etc.
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible; // <~ This definition is valid, just not object-safe.
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
fn main() {
let x: &dyn Foo = &&(); // <~ THIS is where we emit an error.
}
```
#### Regressions
From a recent crater run, there's only one crate that relies on this behavior: https://github.com/rust-lang/rust/pull/124305#issuecomment-2122381740. The crate looks unmaintained and there seems to be no dependents.
#### Further
We may later choose to relax this (e.g. when the where clause is implied by the supertraits of the trait or something), but this is not something I propose to do in this FCP.
For example, given:
```
trait Tr {
fn f(&self) where Self: Blanket;
}
impl<T: ?Sized> Blanket for T {}
```
Proving that some placeholder `S` implements `S: Blanket` would be sufficient to prove that the same (blanket) impl applies for both `Concerete: Blanket` and `dyn Trait: Blanket`.
Repeating here that I don't think we need to implement this behavior right now.
----
r? lcnr
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 flag propagates cargo configs to `rustc-perf --cargo-config`,
which is particularly useful when the environment is air-gapped,
and you want to use the default set of training crates vendored
in the rustc-src tarball.
Technically, wiping bootstrap builds can increase the build time.
But in practice, trying to manually resolve post-bump issues and
even accidentally removing the entire build directory will result
in a much greater loss of time. After all, the bootstrap build process
is not a particularly lengthy operation.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
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".
remove tracing tree indent lines
This allows vscode to collapse nested spans without having to manually remove the indent lines. This is incredibly useful when logging the new solver. I don't mind making them optional depending on some environment flag if you prefer using indent lines
For a gist of the new output, see https://gist.github.com/lcnr/bb4360ddbc5cd4631f2fbc569057e5eb#file-example-output-L181
r? `@oli-obk`
Fix "local crate" detection
`PackageId` is an opaque identifier whose internal format is subject to change, so looking up the names of local crates by ID is more robust than parsing the ID.
Resolves#3643.
compiletest: Unify `cmd2procres` with `run_command_to_procres`
Historical context: I originally added `run_command_to_procres` in #112300 and #114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code.
Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
drop_in_place: weaken the claim of equivalence with drop(ptr.read())
The two are *not* semantically equivalent in all cases, so let's not be so definite about this.
Fixes https://github.com/rust-lang/rust/issues/112015
Make `body_owned_by` return the `Body` instead of just the `BodyId`
fixes#125677
Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly.
This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too.
I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
Streamline `x fmt` and improve its output
- Removes the ability to pass paths to `x fmt`, because it's complicated and not useful, and adds `--all`.
- Improves `x fmt` output.
- Improves `x fmt`'s internal code.
r? ``@GuillaumeGomez``
Rollup of 7 pull requests
Successful merges:
- #124655 (Add `-Zfixed-x18`)
- #125693 (Format all source files in `tests/coverage/`)
- #125700 (coverage: Avoid overflow when the MC/DC condition limit is exceeded)
- #125705 (Reintroduce name resolution check for trying to access locals from an inline const)
- #125708 (tier 3 target policy: clarify the point about producing assembly)
- #125715 (remove unneeded extern crate in rmake test)
- #125719 (Extract coverage-specific code out of `compiletest::runtest`)
r? `@ghost`
`@rustbot` modify labels: rollup
Extract coverage-specific code out of `compiletest::runtest`
I had been vaguely intending to do this for a while, but seeing #89475 on the compiletest dashboard inspired me to actually go and do it.
This moves a few hundred lines of coverage-specific code out of the main module, making navigation a bit easier. There is still a small amount of coverage-specific logic in broader functions in that module, since it can't easily be moved.
This is just cut-and-paste plus fixing visibility and imports, so no functional changes.
I also removed the unit test for anonymizing line numbers in MC/DC reports, as foreshadowed by the comment I wrote when adding it. That functionality is now adequately exercised by the actual snapshot tests for MC/DC coverage.
(Removing the test now avoids the need to move it, or to make the function it calls visible.)
tier 3 target policy: clarify the point about producing assembly
I think that is already the intended meaning of the policy, but I am not sure.
Cc ``@rust-lang/compiler``
Use `rmake` for `windows-` run-make tests
Convert some Makefile tests to recipes.
I renamed "issue-85441" to "windows-ws2_32" as I think it's slightly more descriptive. EDIT: `llvm-readobj` seems to work for reading DLL imports so I've used that instead of `objdump`.
cc #121876
We want to only demand that we check for all components we expect
if we actually built the components we expect, which means
we built the LLVM. Otherwise, it isn't worth checking.
don't inhibit random field reordering on repr(packed(1))
`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).
We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.
This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):
> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
Currently, `x fmt` can print two lists of files.
- The untracked files that are skipped. Always done if within a git
repo.
- The modified files that are formatted.
But if you run with `--all` (or with `GITHUB_ACTIONS=true`) it doesn't
print anything about which files are formatted.
This commit increases consistency.
- The formatted/checked files are now always printed. And it makes it clear why
a file was formatted, e.g. with "modified".
- It uses the same code for both untracked files and formatted/checked
files. This means that now if there are a lot of untracked files just
the number will be printed, which is like the old behaviour for
modified files.
Example output:
```
fmt: skipped 31 untracked files
fmt: formatted modified file compiler/rustc_mir_transform/src/instsimplify.rs
fmt: formatted modified file compiler/rustc_mir_transform/src/validate.rs
fmt: formatted modified file library/core/src/ptr/metadata.rs
fmt: formatted modified file src/bootstrap/src/core/build_steps/format.rs
```
or (with `--all`):
```
fmt: checked 3148 files
```
- Precede them all with `fmt` so it's clear where they are coming from.
- Use `error:` and `warning:` when appropriate.
- Print warnings to stderr instead of stdout
By default, `x fmt` formats/checks modified files. But it also lets you
choose one or more paths instead.
This adds significant complexity to `x fmt`. Explicit paths are
specified via `WalkBuilder::add` rather than `OverrideBuilder::add`. The
`ignore` library is not simple, and predicting the interactions between
the two mechanisms is difficult.
Here's a particularly interesting case.
- You can request a path P that is excluded by the `ignore` list in the
`rustfmt.toml`. E.g. `x fmt tests/ui/` or `x fmt tests/ui/bitwise.rs`.
- `x fmt` will add P to the walker (via `WalkBuilder::add`), traverse it
(paying no attention to the `ignore` list from the `rustfmt.toml`
file, due to the different mechanism), and call `rustfmt` on every
`.rs` file within it.
- `rustfmt` will do nothing to those `.rs` files, because it *also*
reads `rustfmt.toml` and sees that they match the `ignore` list!
It took me *ages* to debug and understand this behaviour. Not good!
`x fmt` even lets you name a path below the current directory. This was
intended to let you do things like `x fmt std` that mirror things like
`x test std`. This works by looking for `std` and finding `library/std`,
and then formatting that. Unfortuantely, this motivating case now gives
an error. When support was added in #107944, `library/std` was the only
directory named `std`. Since then, `tests/ui/std` was added, and so `x
fmt std` now gives an error.
In general, explicit paths don't seem particularly useful. The only two
cases `x fmt` really needs are:
- format/check the files I have modified (99% of uses)
- format/check all files
(While respecting the `ignore` list in `rustfmt.toml`, of course.)
So this commit moves to that model. `x fmt` will now give an error if
given an explicit path. `x fmt` now also supports a `--all` option. (And
running with `GITHUB_ACTIONS=true` also causes everything to be
formatted/checked, as before.) Much simpler!
Support `./x doc run-make-support --open`
Having easy access to the run-make-support documentation is invaluable when creating run-make tests using the new Rust recipes.
Make more of the test suite run on Mac Catalyst
Combined with https://github.com/rust-lang/rust/pull/125225, the only failing parts of the test suite are in `tests/rustdoc-js`, `tests/rustdoc-js-std` and `tests/debuginfo`. Tested with:
```console
./x test --target=aarch64-apple-ios-macabi library/std
./x test --target=aarch64-apple-ios-macabi --skip=tests/rustdoc-js --skip=tests/rustdoc-js-std --skip=tests/debuginfo tests
```
Will probably put up a PR later to enable _running_ on (not just compiling for) Mac Catalyst in CI, though not sure where exactly I should do so? `src/ci/github-actions/jobs.yml`?
Note that I've deliberately _not_ enabled stack overflow handlers on iOS/tvOS/watchOS/visionOS (see https://github.com/rust-lang/rust/issues/25872), but rather just skipped those tests, as it uses quite a few APIs that I'd be weary about getting rejected by the App Store (note that Swift doesn't do it on those platforms either).
r? ``@workingjubilee``
CC ``@thomcc``
``@rustbot`` label O-ios O-apple
Add `--print=check-cfg` to get the expected configs
This PR adds a new `--print` variant `check-cfg` to get the expected configs.
Details and rational can be found on the MCP: https://github.com/rust-lang/compiler-team/issues/743
``@rustbot`` label +F-check-cfg +S-waiting-on-MCP
r? ``@petrochenkov``
Update cargo
5 commits in a8d72c675ee52dd57f0d8f2bae6655913c15b2fb..431db31d0dbeda320caf8ef8535ea48eb3093407
2024-05-24 03:34:17 +0000 to 2024-05-28 18:17:31 +0000
- Include `lints.rust.unexpected_cfgs.check-cfg` in the fingerprint (rust-lang/cargo#13958)
- feat(test): Auto-redact elapsed time (rust-lang/cargo#13973)
- chore: Update to snapbox 0.6 (rust-lang/cargo#13963)
- fix: check if rev is full commit sha for github fast path (rust-lang/cargo#13969)
- test: switch from `drop` to `let _` due to nightly rustc change (rust-lang/cargo#13964)
r? ghost
`PackageId` is an opaque identifier whose internal format is subject to
change, so looking up the names of local crates by ID is more robust
than parsing the ID.
Resolves#3643.
rustfmt fixes
The `rmake.rs` entries in `rustfmt.toml` are causing major problems for `x fmt`. This PR removes them and does some minor related cleanups.
r? ``@GuillaumeGomez``
This adds the `only-apple`/`ignore-apple` compiletest directive, and
uses that basically everywhere instead of `only-macos`/`ignore-macos`.
Some of the updates in `run-make` are a bit redundant, as they use
`ignore-cross-compile` and won't run on iOS - but using Apple in these
is still more correct, so I've made that change anyhow.
It's reasonable to want to, but in the current implementation this
causes multiple problems.
- All the `rmake.rs` files are formatted every time even when they
haven't changed. This is because they get whitelisted unconditionally
in the `OverrideBuilder`, before the changed files get added.
- The way `OverrideBuilder` works, if any files gets whitelisted then no
unmentioned files will get traversed. This is surprising, and means
that the `rmake.rs` entries broke the use of explicit paths to `x
fmt`, and also broke `GITHUB_ACTIONS=true git check --fmt`.
The commit removes the `rmake.rs` entries, fixes the formatting of a
couple of files that were misformatted (not previously caught due to the
`GITHUB_ACTIONS` breakage), and bans `!`-prefixed entries in
`rustfmt.toml` because they cause all these problems.
Some are too long, some aren't complete sentences, some are complete
sentences but don't bother with an upper case letter at the start. All
annoying and hurt readability.
Rollup of 4 pull requests
Successful merges:
- #125339 (The number of tests does not depend on the architecture's pointer width)
- #125542 (Migrate rustdoc verify output files)
- #125616 (MIR validation: ensure that downcast projection is followed by field projection)
- #125625 (Use grep to implement verify-line-endings)
Failed merges:
- #125573 (Migrate `run-make/allow-warnings-cmdline-stability` to `rmake.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
Use grep to implement verify-line-endings
Unless I'm missing something (which I might be!) then `verify-line-endings` is easy to implement with `grep` rather than using a bespoke tool with varying availability.
rustdoc: Clarify const-stability with regard to normal stability
Fixes#125511.
- Elide const-unstable if also unstable overall
- Show "const" for const-unstable if also overall unstable
Add `toggle_async_sugar` assist code action
Implement code action for sugaring and de-sugaring asynchronous functions.
This code action does not import `Future` trait when de-sugaring and does not touch function boby, I guess this can be implemented later if needed. This action also does not take into consideration other bounds because IMO it's usually "let me try to use sugared version here".
Feel free to request changes, that's my first code action implementation 😄Closes#17010
Relates to #16195
Implement assist to switch between doc and normal comments
Hey first PR to rust-analyzer to get my feet wet with the code base. It's an assist to switch a normal comment to a doc comment and back, something I've found myself doing by hand a couple of times.
I shamelessly stole `relevant_line_comments` from `convert_comment_block`, because I didn't see any inter-assist imports happening in the files I peeked at so I thought this would be preferable.
Fix `data_constructor` ignoring generics for struct
Previously didn't work for structs with generics due to `field.ty()` having placeholders in type.
_Enums were handeled correctly already._
Also renamed `type_constructor -> data_constructor` as this is more correct name for it
interpret: get rid of 'mir lifetime
I realized our MIR bodies are actually at lifetime `'tcx`, so we don't need to carry around this other lifetime everywhere.
r? `@oli-obk`
[perf] Delay the construction of early lint diag structs
Attacks some of the perf regressions from https://github.com/rust-lang/rust/pull/124417#issuecomment-2123700666.
See individual commits for details. The first three commits are not strictly necessary.
However, the 2nd one (06bc4fc671, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement.
It's also pretty sweet on its own if I may say so myself.
Remove `DefId` from `EarlyParamRegion`
Currently we represent usages of `Region` parameters via the `ReEarlyParam` or `ReLateParam` variants. The `ReEarlyParam` is effectively equivalent to `TyKind::Param` and `ConstKind::Param` (i.e. it stores a `Symbol` and a `u32` index) however it also stores a `DefId` for the definition of the lifetime parameter.
This was used in roughly two places:
- Borrowck diagnostics instead of threading the appropriate `body_id` down to relevant locations. Interestingly there were already some places that had to pass down a `DefId` manually.
- Some opaque type checking logic was using the `DefId` field to track captured lifetimes
I've split this PR up into a commit for generate rote changes to diagnostics code to pass around a `DefId` manually everywhere, and another commit for the opaque type related changes which likely require more careful review as they might change the semantics of lints/errors.
Instead of manually passing the `DefId` around everywhere I previously tried to bundle it in with `TypeErrCtxt` but ran into issues with some call sites of `infcx.err_ctxt` being unable to provide a `DefId`, particularly places involved with trait solving and normalization. It might be worth investigating adding some new wrapper type to pass this around everywhere but I think this might be acceptable for now.
This pr also has the effect of reducing the size of `EarlyParamRegion` from 16 bytes -> 8 bytes. I wouldn't expect this to have any direct performance improvement however, other variants of `RegionKind` over `8` bytes are all because they contain a `BoundRegionKind` which is, as far as I know, mostly there for diagnostics. If we're ever able to remove this it would shrink the `RegionKind` type from `24` bytes to `12` (and with clever bit packing we might be able to get it to `8` bytes). I am curious what the performance impact would be of removing interning of `Region`'s if we ever manage to shrink `RegionKind` that much.
Sidenote: by removing the `DefId` the `Debug` output for `Region` has gotten significantly nicer. As an example see this opaque type debug print before vs after this PR:
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), [DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0, T, DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0])`
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), ['a/#0, T, 'a/#0])`
r? `@compiler-errors` (I would like someone who understands the opaque type setup to atleast review the type system commit, but the rest is likely reviewable by anyone)
If a const function is unstable overall (and thus, in all circumstances
I know of, also const-unstable), we should show the option to use it as
const. You need to enable a feature to use the function at all anyway.
If the function is stabilized without also being const-stabilized, then
we do not show the const keyword and instead show "const: unstable" in
the version info.
Try to not reinstall tools in mingw CI
Reinstalling the tools seems prone to failure (e.g. [latest](https://github.com/rust-lang/rust/pull/125529#issuecomment-2130919307)) and is more work. It also seems unnecessary as CI actually uses a vendored tarball for builds.
cc `@mati865`
completely refactor how we manage blocking and unblocking threads
This hides a lot of invariants from the implementation of the synchronization primitives, and makes sure we never have to release or acquire a vector clock on another thread but the active one.
fix(opt-dist): respect existing config.toml
This is another step toward making opt-dist work in sandboxed environments. See also <https://github.com/rust-lang/rust/pull/125465>.
opt-dist verifies the final built rustc against a subset of rustc test
suite. However it overwrote the pre-existing `config.toml` [^1],
and that results in ./vendor/ directory removed [^2].
Instead of overwriting, this patch use `--set <config-value>` to
override paths to rustc / cargo / llvm-config.
[^1]: 606afbb617/src/tools/opt-dist/src/tests.rs (L62-L77)
[^2]: 8679004993/src/bootstrap/bootstrap.py (L1057)
tidy: stop special-casing tests/ui entry limit
It is genuinely more annoying to have this error, now that this value is below the general `ENTRY_LIMIT` cap, when one is trying to clean out tests from tests/ui! This code has served its purpose well, let it rest now rather than force it to continue haunting us.
Avoid clone when constructing runnable label.
I stumbled across this when reading this code. This seems like an unnecessary allocation (though likely small?)
It's confusing because if a function is unstable overall, there's no
need to highlight the constness is also unstable. Technically, these
attributes (overall stability and const-stability) are separate, but in
practice, we don't even show the const-unstable's feature flag (it's
normally the same as the overall function).
This is another step toward making opt-dist work in sandboxed environments
opt-dist verifies the final built rustc against a subset of rustc test
suite. However it overwrote the pre-existing `config.toml` [^1],
and that results in ./vendor/ directory removed [^2].
Instead of overwriting, this patch use `--set <config-value>` to
override paths to rustc / cargo / llvm-config.
[^1]: 606afbb617/src/tools/opt-dist/src/tests.rs (L62-L77)
[^2]: 8679004993/src/bootstrap/bootstrap.py (L1057)
Rollup of 7 pull requests
Successful merges:
- #121377 (Stabilize `LazyCell` and `LazyLock`)
- #122986 (Fix c_char on AIX)
- #123803 (Fix `VecDeque::shrink_to` UB when `handle_alloc_error` unwinds.)
- #124080 (Some unstable changes to where opaque types get defined)
- #124667 (Stabilize `div_duration`)
- #125472 (tidy: validate LLVM component names in tests)
- #125523 (Exit the process a short time after entering our ctrl-c handler)
r? `@ghost`
`@rustbot` modify labels: rollup
tidy: validate LLVM component names in tests
LLVM component names are not immediately obvious (they usually omit any suffixes on the target arch name), and if they're incorrect, the test will silently never run.
This happened [here](https://github.com/rust-lang/rust/pull/125220#discussion_r1612626002), and it would be nice to prevent it.
Stabilize `LazyCell` and `LazyLock`
Closes#109736
This stabilizes the [`LazyLock`](https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html) and [`LazyCell`](https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html) types:
```rust
static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| {
println!("initializing");
let mut m = HashMap::new();
m.insert(13, "Spica".to_string());
m.insert(74, "Hoyten".to_string());
m
});
let lazy: LazyCell<i32> = LazyCell::new(|| {
println!("initializing");
92
});
```
r? libs-api
Rollup of 8 pull requests
Successful merges:
- #125271 (use posix_memalign on almost all Unix targets)
- #125451 (Fail relating constants of different types)
- #125478 (Bump bootstrap compiler to the latest beta compiler)
- #125498 (Stop using the avx512er and avx512pf x86 target features)
- #125510 (remove proof tree formatting, make em shallow)
- #125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate)
- #125514 (Structurally resolve before `builtin_index` in EUV)
- #125527 (Add manual Sync impl for ReentrantLockGuard)
r? `@ghost`
`@rustbot` modify labels: rollup
Bump bootstrap compiler to the latest beta compiler
This PR updates the bootstrap compiler, aka stage0 to the latest beta version, since it contains rust-lang/cargo#13925.
It removes those unconditional Cargo warnings:
```
warning: [...]/rust/library/core/Cargo.toml: unused manifest key: lints.rust.unexpected_cfgs.check-cfg
warning: [...]/rust/library/std/Cargo.toml: unused manifest key: lints.rust.unexpected_cfgs.check-cfg
warning: [...]/rust/library/alloc/Cargo.toml: unused manifest key: lints.rust.unexpected_cfgs.check-cfg
```
for all contributors/users of this repository (including CI).
I don't know if that's something we do, or if it's even advisable, feel free to close.
r? `@Mark-Simulacrum`
Update cargo
7 commits in 84dc5dc11a9007a08f27170454da6097265e510e..a8d72c675ee52dd57f0d8f2bae6655913c15b2fb
2024-05-20 18:57:08 +0000 to 2024-05-24 03:34:17 +0000
- Improve error description when deserializing partial field struct (rust-lang/cargo#13956)
- fix: remove symlink dir on Windows (rust-lang/cargo#13910)
- Fix wrong type of rustc-flags in documentation (rust-lang/cargo#13957)
- Add more high level traces (rust-lang/cargo#13951)
- upgrade gix from 0.62 to 0.63 (rust-lang/cargo#13948)
- Use `i32` rather than `usize` as "default integer" in library template (rust-lang/cargo#13939)
- fetch specific commits even if the github fast path fails (rust-lang/cargo#13946)
r? ghost
