This updates the reference which is now using a new mdbook plugin. This
requires a little extra work than a normal book because the plugin uses
`rustdoc` to generate links to the standard library. It also ensures
that the submodule is available for *any* command that uses rustbook,
since it is now part of the rustbook workspace.
This adds a new method `require_and_update_submodule` to replace
`update_submodule`. This new method will generate an error if the
submodule doesn't actually exist. This replaces some ad-hoc checks that
were performing this function. This helps ensure that a good error
message is always displayed.
This also adds require_and_update_all_submodules which does this for
all submodules.
Ideally this should not have any change other than better error messages
when submodules are missing.
I put this submodule update in the entirely wrong location. I put it in
the `RustcBook` step (for generating src/doc/rustc), when it really
should exist for all steps that use the `Rustbook` tool.
compiler: Never debug_assert in codegen
In the name of Turing and his Hoarey heralds, assert our truths before creating a monster!
The `rustc_codegen_llvm` and `rustc_codegen_ssa` crates are fairly critical for rustc's correctness. Small mistakes here can easily result in undefined behavior, since a "small mistake" can mean something like "link and execute the wrong code". We should probably run any and all asserts in these modules unconditionally on whether this is a "debug build", and damn the costs in performance.
...Especially because the costs in performance seem to be *nothing*. It is not clear how much correctness we gain here, but I'll take free correctness improvements.
Rollup of 5 pull requests
Successful merges:
- #127054 (Reorder trait bound modifiers *after* `for<...>` binder in trait bounds)
- #127528 (Replace ASCII control chars with Unicode Control Pictures)
- #127872 (Migrate `pointer-auth-link-with-c`, `c-dynamic-rlib` and `c-dynamic-dylib` `run-make` tests to rmake)
- #128111 (Do not use question as label)
- #128160 (Don't ICE when auto trait has assoc ty in old solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE when auto trait has assoc ty in old solver
Kinda a pointless change to make, but it's observable w/o the feature gate, so let's just fix it. I reintroduced this ICE when I removed the "auto impl" kind from `ImplSource` in #112687.
Fixes#117829Fixes#127746
Do not use question as label
We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might":
```
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
| ^^^^ you might be missing crate `spam`
|
= help: consider adding `extern crate spam` to use the `spam` crate
```
Migrate `pointer-auth-link-with-c`, `c-dynamic-rlib` and `c-dynamic-dylib` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: i686-mingw
try-job: aarch64-apple
Replace ASCII control chars with Unicode Control Pictures
Replace ASCII control chars like `CR` with Unicode Control Pictures like `␍`:
```
error: bare CR not allowed in doc-comment
--> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32
|
LL | /// doc comment with bare CR: '␍'
| ^
```
Centralize the checking of unicode char width for the purposes of CLI display in one place. Account for the new replacements. Remove unneeded tracking of "zero-width" unicode chars, as we calculate these in the `SourceMap` as needed now.
Reorder trait bound modifiers *after* `for<...>` binder in trait bounds
This PR suggests changing the grammar of trait bounds from:
```
[CONSTNESS] [ASYNCNESS] [?] [BINDER] [TRAIT_PATH]
const async ? for<'a> Sized
```
to
```
([BINDER] [CONSTNESS] [ASYNCNESS] | [?]) [TRAIT_PATH]
```
i.e., either
```
? Sized
```
or
```
for<'a> const async Sized
```
(but not both)
### Why?
I think it's strange that the binder applies "more tightly" than the `?` trait polarity. This becomes even weirder when considering that we (or at least, I) want to have `async` trait bounds expressed like:
```
where T: for<'a> async Fn(&'a ()) -> i32,
```
and not:
```
where T: async for<'a> Fn(&'a ()) -> i32,
```
### Fallout
No crates on crater use this syntax, presumably because it's literally useless. This will require modifying the reference grammar, though.
### Alternatives
If this is not desirable, then we can alternatively keep parsing `for<'a>` after the `?` but deprecate it with either an FCW (or an immediate hard error), and begin parsing `for<'a>` *before* the `?`.
Rollup of 8 pull requests
Successful merges:
- #122192 (Do not try to reveal hidden types when trying to prove auto-traits in the defining scope)
- #126042 (Implement `unsigned_signed_diff`)
- #126548 (Improved clarity of documentation for std::fs::create_dir_all)
- #127717 (Fix malformed suggestion for repeated maybe unsized bounds)
- #128046 (Fix some `#[cfg_attr(not(doc), repr(..))]`)
- #128122 (Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps`)
- #128135 (std: use duplicate thread local state in tests)
- #128140 (Remove Unnecessary `.as_str()` Conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might":
```
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
| ^^^^ you might be missing crate `spam`
|
= help: consider adding `extern crate spam` to use the `spam` crate
```
Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps`
We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on the old behavior are reported when used as dependencies.
Tracking issue: <https://github.com/rust-lang/rust/issues/128143>
Fix malformed suggestion for repeated maybe unsized bounds
Fixes#127441
Now when we encounter something like `foo(a : impl ?Sized + ?Sized)`, instead of suggesting removal of both bounds and leaving `foo(a: impl )` behind, we suggest changing the first bound to `Sized` and removing the second bound, resulting in `foo(a: impl Sized)`.
Although the issue was reported for impl trait types, it also occurred with regular param bounds. So if we encounter `foo<T: ?Sized + ?Sized>(a: T)` we now detect that all the bounds are `?Sized` and therefore emit the suggestion to remove the entire predicate `: ?Sized + ?Sized` resulting in `foo<T>(a: T)`.
Lastly, if we encounter a situation where some of the bounds are something other than `?Sized`, then we emit separate removal suggestions for each `?Sized` bound. E.g. if we see `foo(a: impl ?Sized + Bar + ?Sized)` or `foo<T: ?Sized + Bar + ?Sized>(a: T)` we emit suggestions such that the user will be left with `foo(a : impl Bar)` or `foo<T: Bar>(a: T)` respectively.
Implement `unsigned_signed_diff`
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Implements https://github.com/rust-lang/rust/issues/126041
Do not try to reveal hidden types when trying to prove auto-traits in the defining scope
fixes#99793
this avoids the cycle error by just causing a selection error, which is not fatal. We pessimistically assume that freeze does not hold, which is always a safe assumption.
rustdoc: clean up and fix ord violations in item sorting
Based on https://github.com/rust-lang/rust/pull/128139 with a few minor changes:
- The name sorting function is changed to follow the [version sort] from the style guide
- the `cmp` function is redesigned to more obviously make a partial order, by always return `cmp()` of the same variable as the `!=` above
[version sort]: https://doc.rust-lang.org/nightly/style-guide/index.html#sorting
Based on e3fdafc263 with a few
minor changes:
- The name sorting function is changed to follow the [version sort]
from the style guide
- the `cmp` function is redesigned to more obviously make a
partial order, by always return `cmp()` of the same variable as
the `!=` above
[version sort]: https://doc.rust-lang.org/nightly/style-guide/index.html#sorting
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
We are moving toward forbidding `missing_fragment_specifier` either in
edition 2024 or unconditionally. Make a first step toward this by
ensuring crates that rely on the old behavior are reported when used as
dependencies.
Tracking issue: <https://github.com/rust-lang/rust/issues/128143>
Rollup of 9 pull requests
Successful merges:
- #126152 (size_of_val_raw: for length 0 this is safe to call)
- #127252 (Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methods)
- #127374 (Tweak "wrong # of generics" suggestions)
- #127457 (Make tidy fast without compromising case alternation)
- #127480 (Fix build failure on vxworks #127084 )
- #127733 (Replace some `mem::forget`'s with `ManuallyDrop`)
- #128120 (Gate `AsyncFn*` under `async_closure` feature)
- #128131 (Import `c_void` rather than using the full path)
- #128133 (Improve spans on evaluated `cfg_attr`s.)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve spans on evaluated `cfg_attr`s.
When converting something like `#![cfg_attr(cond, attr)]` into `#![attr]`, we currently duplicate the `#` token and the `!` token. But weirdly, there is also this comment:
// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.
Maybe that comment used to be true? But now it is false: we can duplicate the existing delimiters (and their spans and spacing), much like we do for the `#` and `!`.
This commit does that, thus removing the incorrect comment, and improving the spans on `Group`s in a few proc-macro tests.
`@petrochenkov`
Import `c_void` rather than using the full path
Follow up to #128092. As requested, this imports `c_void` in more places. I also fixed up some imports to use `core` for core types instead of `crate`. While that is not strictly necessary, I think ideally things in `sys/pal` should only depend on itself or core so that the code is less spaghetti. We're far away from that ideal at the moment but I can at least try to slowly move in that direction.
Also this forbids `unsafe_op_in_unsafe_fn` for library/std/src/sys/pal/windows by fixing up the remaining unsafe bits that are just punting their unsafe requirements onto the caller of the `unsafe` function (or definition macro).
<!--
r? workingjubilee
-->
Gate `AsyncFn*` under `async_closure` feature
T-lang has not come to a consensus on the naming of async closure callable bounds, and as part of allowing the async closures RFC merge, we agreed to place `AsyncFn` under the same gate as `async Fn` so that these syntaxes can be evaluated in parallel.
See https://github.com/rust-lang/rfcs/pull/3668#issuecomment-2246435537
r? oli-obk
Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
Fix build failure on vxworks #127084
PR to address issue #127084 .
1. Skip `reset_segpipe` for vxworks
2. Return unimplemented error for vxworks from settimes and lchown
3. Temporarily skip dirfd for vxworks
4. Add allow unused unsafe on read_at and write_at functions in unix/fs.rs
5. Using cfg disable ON_BROKEN_PIPE_FLAG_USED and on_broken_pipe_flag_used() for vxworks
6. Remove old crate::syscommon:🧵:min_stack() reference from process_vxworks.rs and update to set stack size of rtpthread
Thank you.
Make tidy fast without compromising case alternation
Fixes tidy speed issue but still catches case-alternation, enabled for other `style.rs` files, and also detects test files better.
r? `@albertlarsan68`
`@Nilstrieb`
Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methods
Some architectures (i386) do not define a "count leading zeros" instruction, they define a "find first set bit" instruction (`bsf`) whose result is undefined when given zero (ie none of the bits are set). Of this family of bitwise operations, I always forget which of these things is potentially undefined for zero, and I'm also not 100% sure that Rust provides a hard guarantee for the results of these methods when given zero. So I figured there are others who have these same uncertainties, and it would be good to resolve them and answer the question via extending these doc examples/tests.
See https://en.wikipedia.org/wiki/Find_first_set#Hardware_support for more info on i386 and `bsf` on zero.
