As decided in rust-lang/compiler-team#750.
Use declarations are currently wildly inconsistent because rustfmt is
quite unopinionated about how they should be formatted. The
`rustfmt.toml` additions makes rustfmt more opinionated, which avoids
the need for any decision when adding new use declarations to a file.
This commit only updates `rustfmt.toml` and
`compiler/rustc_codegen_cranelift/rustfmt.toml`. The next commit will do
the reformatting.
Add links from `assert_eq!` docs to `debug_assert_eq!`, etc.
This adds information and links from the docs for the following macros to their debug-only versions:
* `assert_eq!`
* `assert_ne!`
* `assert_matches!`
This matches the existing documentation for the `assert!` macro.
Stabilize `const_waker`
Closes: https://github.com/rust-lang/rust/issues/102012.
For `local_waker` and `context_ext` related things, I just ~~moved them to dedicated feature gates and reused their own tracking issue (maybe it's better to open a new one later, but at least they should not be tracked under https://github.com/rust-lang/rust/issues/102012 from the beginning IMO.)~~ reused their own feature gates as suggested by ``@tgross35.``
``@rustbot`` label: +T-libs-api
r? libs-api
add `is_multiple_of` for unsigned integer types
tracking issue: https://github.com/rust-lang/rust/issues/128101
This adds the `.is_multiple_of` method on unsigned integers.
Returns `true` if `self` is an integer multiple of `rhs`, and false otherwise.
This function is equivalent to `self % rhs == 0`, except that it will not panic for `rhs == 0`. Instead, `0.is_multiple_of(0) == true`, and for any non-zero `n`, `n.is_multiple_of(0) == false`.
deps: dedup object, wasmparser, wasm-encoder
* dedups one `object`, additional dupe will be removed, with next `thorin-dwp` update
* `wasmparser` pinned to minor versions, so full merge isn't possible
* same with `wasm-encoder`
Turned off some features for `wasmparser` (see features https://github.com/bytecodealliance/wasm-tools/blob/v1.208.1/crates/wasmparser/Cargo.toml) in `run-make-support`, looks working?
Fix doc nits
Many tiny changes to stdlib doc comments to make them consistent (for example "Returns foo", rather than "Return foo"), adding missing periods, paragraph breaks, backticks for monospace style, and other minor nits.
[rustdoc] Add copy code feature
This PR adds a "copy code" to code blocks. Since this is a JS only feature, the HTML is generated with JS when the user hovers the code block to prevent generating DOM unless needed.
Two things to note:
1. I voluntarily kept the current behaviour of the run button (only when hovering a code block with a mouse) so it doesn't do anything on mobile. I plan to send a follow-up where the buttons would "expandable" or something. Still need to think which approach would be the best.
2. I used a picture and not text like the run button to remain consistent with the "copy path" button. I'd also prefer for the run button to use a picture (like what is used in mdbook) but again, that's something to be discussed later on.
The rendering looks like this:
It can be tested [here](https://guillaume-gomez.fr/rustdoc/bar/struct.Bar.html) (without the run button) and [here](https://guillaume-gomez.fr/rustdoc/foo/struct.Bar.html) (with the run button).
Fixes#86851.
r? ``@notriddle``
Don't manually implement `PartialEq` for some types in `rustc_type_ir`
> > As a follow-up, we should look at not manually implementing PartialEq for these types but instead going thru a derive
>
> I will try to tackle this later in a separate PR
https://github.com/rust-lang/rust/issues/127042#issuecomment-2218838446
Update the reference
This updates the reference to use the new mdbook-spec preprocessor, which is a Cargo library inside the reference submodule.
Note that this PR contains a bunch of bootstrap cleanup commits to assist with making sure the submodules are working correctly. All of the cleanup PRs should have a description in their commit. I'd be happy to move those to a separate PR if that makes review easier.
The main changes for the reference are:
- Move the `doc::Reference` bootstrap step out of the generic macro into a custom step.
- This step needs to build rustdoc because the new mdbook-spec plugin uses rustdoc for generating links.
- PATH is updated so that the rustdoc binary can be found.
- rustbook now includes the mdbook-spec plugin as a dependency.
- rustbook enables the mdbook-spec preprocessor.
I did a bunch of testing with the various commands and setups, such as:
- `submodules=true` and `submodules=false`
- having all submodules deinitialized
- not in a git repository
However, there are probably thousands of different permutations of different commands, settings, and environments, so there is a chance I'm missing something.
Add migration lint for 2024 prelude additions
This adds the migration lint for the newly ambiguous methods `poll` and `into_future`. When these methods are used on types implementing the respective traits, it will be ambiguous in the future, which can lead to hard errors or behavior changes depending on the exact circumstances.
tracked by #121042
<!--
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>
-->
r? compiler-errors as the method prober
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of https://github.com/rust-lang/rust/pull/127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just `run`, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
try-job: x86_64-msvc
This adds the migration lint for the newly ambiguous methods `poll` and
`into_future`. When these methods are used on types implementing the
respective traits, it will be ambiguous in the future, which can lead to
hard errors or behavior changes depending on the exact circumstances.
`#[naked]`: report incompatible attributes
tracking issue: https://github.com/rust-lang/rust/issues/90957
this is a re-implementation of https://github.com/rust-lang/rust/pull/93809 by ``@bstrie`` which was closed 2 years ago due to inactivity.
This PR takes some of the final comments into account, specifically providing a little more context in error messages, and using an allow list to determine which attributes are compatible with `#[naked]`.
Notable attributes that are incompatible with `#[naked]` are:
* `#[inline]`
* `#[track_caller]`
* ~~`#[target_feature]`~~ (this is now allowed, see PR discussion)
* `#[test]`, `#[ignore]`, `#[should_panic]`
These attributes just directly conflict with what `#[naked]` should do.
Naked functions are still important for systems programming, embedded, and operating systems, so I'd like to move them forward.
Migrate `static-dylib-by-default`, `sanitizer-dylib-link`, `sanitizer-cdylib-link` and `sanitizer-staticlib-link` `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: armhf-gnu
try-job: test-various
try-job: i686-msvc
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
Rollup of 8 pull requests
Successful merges:
- #125897 (from_ref, from_mut: clarify documentation)
- #128207 (improve error message when `global_asm!` uses `asm!` options)
- #128241 (Remove logic to suggest clone of function output)
- #128259 ([illumos/solaris] set MSG_NOSIGNAL while writing to sockets)
- #128262 (Delete `SimplifyArmIdentity` and `SimplifyBranchSame` tests)
- #128266 (update `rust.channel` default value documentation)
- #128267 (Add rustdoc GUI test to check title with and without search)
- #128271 (Disable jump threading of float equality)
r? `@ghost`
`@rustbot` modify labels: rollup
Disable jump threading of float equality
Jump threading stores values as `u128` (`ScalarInt`) and does its comparisons for equality as integer comparisons.
This works great for integers. Sadly, not everything is an integer.
Floats famously have wonky equality semantcs, with `NaN!=NaN` and `0.0 == -0.0`. This does not match our beautiful integer bitpattern equality and therefore causes things to go horribly wrong.
While jump threading could be extended to support floats by remembering that they're floats in the value state and handling them properly, it's signficantly easier to just disable it for now.
fixes#128243
Delete `SimplifyArmIdentity` and `SimplifyBranchSame` tests
These two passes have already been deleted in #107256. I'm not sure why tidy didn't catch it.
As regression tests, I didn't delete `tests/ui/mir/issue-66851.rs` and `tests/ui/mir/simplify-branch-same.rs`.
r? compiler
[illumos/solaris] set MSG_NOSIGNAL while writing to sockets
Both these platforms have MSG_NOSIGNAL available, and we should set it for socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL (i.e. terminate the process).
I've verified via a quick program at
https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE handler is reset to SIG_DFL, writes to closed TCP sockets now error out with EPIPE. (Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.)
However, I couldn't find any existing tests which verified the MSG_NOSIGNAL behavior.
Remove logic to suggest clone of function output
I can't exactly tell, but I believe that this suggestion is operating off of a heuristic that the lifetime of a function's input is correlated with the lifetime of a function's output in such a way that cloning would fix an error. I don't think that actually manages to hit the bar of "actually provides useful suggestions" most of the time.
Specifically, I've hit false-positives due to this suggestion *twice* when fixing ICEs in the compiler, so I don't think it's worthwhile having this logic around. Neither of the two affected UI tests are actually fixed by the suggestion.
improve error message when `global_asm!` uses `asm!` options
specifically, what was
error: expected one of `)`, `att_syntax`, or `raw`, found `preserves_flags`
--> $DIR/bad-options.rs:45:25
|
LL | global_asm!("", options(preserves_flags));
| ^^^^^^^^^^^^^^^ expected one of `)`, `att_syntax`, or `raw`
is now
error: the `preserves_flags` option cannot be used with `global_asm!`
--> $DIR/bad-options.rs:45:25
|
LL | global_asm!("", options(preserves_flags));
| ^^^^^^^^^^^^^^^ the `preserves_flags` option is not meaningful for global-scoped inline assembly
mirroring the phrasing of the [reference](https://doc.rust-lang.org/reference/inline-assembly.html#options).
This is also a bit of a refactor for a future `naked_asm!` macro (for use in `#[naked]` functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. With `naked_asm!` added to the mix hitting this error is more likely.
from_ref, from_mut: clarify documentation
This was brought up [here](https://github.com/rust-lang/rust/issues/56604#issuecomment-2143193486). The domain of quantification is generally always constrained by the type in the type signature, and I am not sure it's always worth spelling that out explicitly as that makes things exceedingly verbose. But since this was explicitly brought up, let's clarify.
I misread this one. It is only checking if LLVM needs to be rebuilt.
There is code below that handles the case where it is unable to compute
the stamp if the source is missing.
These are required 100% of the time, but they are almost always required
for any command that runs Cargo in the main workspace.
Ideally, initializing these two standard library submodules would be
lazy and only initialized when required (see
https://github.com/rust-lang/rust/pull/82653). However, it would require
updating these in almost every Step (anything that runs `cargo` in the
main workspace).
