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
Implement feature `integer_sign_cast`
Tracking issue: https://github.com/rust-lang/rust/issues/125882
Since this is my first time making a library addition I wasn't sure where to place the new code relative to existing code. I decided to place it near the top where there are already some other basic bitwise manipulation functions. If there is an official guideline for the ordering of functions, please let me know.
Change f32::midpoint to upcast to f64
This has been verified by kani as a correct optimization
see: https://github.com/rust-lang/rust/issues/110840#issuecomment-1942587398
The new implementation is branchless and only differs in which NaN values are produced (if any are produced at all), which is fine to change. Aside from NaN handling, this implementation produces bitwise identical results to the original implementation.
Question: do we need a codegen test for this? I didn't add one, since the original PR #92048 didn't have any codegen tests.
std::pal::unix::thread fetching min stack size on netbsd.
PTHREAD_STACK_MIN is not defined however sysconf/_SC_THREAD_STACK_MIN returns it as it can vary from arch to another.
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.
Add some more specific checks to the MIR validator
None of the `PointerCoercion`s had any checks, so while there's probably more that could be done here, hopefully these are better than the previous nothing.
r? mir
Make repr(packed) vectors work with SIMD intrinsics
In #117116 I fixed `#[repr(packed, simd)]` by doing the expected thing and removing padding from the layout. This should be the last step in providing a solution to rust-lang/portable-simd#319
compiletest: split rmake.rs executable from scratch directory
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 (as observed in PRs like https://github.com/rust-lang/rust/pull/125752#issuecomment-2142577084) 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 output artifacts directory:
```
base_dir/
rmake.exe
rmake_out/
```
We construct a base directory, unique to each run-make test, under which we place rmake.exe alongside a `rmake_out/` directory. This `rmake_out/` 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`.
This wasn't a problem for Makefile tests because there's no exe file under `$TMPDIR` whose process is still running when `rm -rf $TMPDIR` is called.
try-job: x86_64-msvc
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.
This has been verified by kani as a correct optimization
see: https://github.com/rust-lang/rust/issues/110840#issuecomment-1942587398
The new implementation is branchless, and only differs in which NaN
values are produced (if any are produced at all). Which is fine to change.
Aside from NaN handling, this implementation produces bitwise identical
results to the original implementation.
The new implementation is gated on targets that have a fast 64-bit
floating point implementation in hardware, and on WASM.
Unroll first iteration of checked_ilog loop
This follows the optimization of #115913. As shown in https://github.com/rust-lang/rust/pull/115913#issuecomment-2066788006, the performance was improved in all important cases, but some regressions were introduced for the benchmarks `u32_log_random_small`, `u8_log_random` and `u8_log_random_small`.
Basically, #115913 changed the implementation from one division per iteration to one multiplication per iteration plus one division. When there are zero iterations, this is a regression from zero divisions to one division.
This PR avoids this by avoiding the division if we need zero iterations by returning `Some(0)` early. It also reduces the number of multiplications by one in all other cases.
Reject `CVarArgs` in `parse_ty_for_where_clause`
Fixes#125847. This regressed in #77035 where the `parse_ty` inside `parse_ty_where_predicate` was replaced with the at the time new `parse_ty_for_where_clause` which incorrectly stated it would permit CVarArgs (maybe a copy/paste error).
r? parser
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.
Check index `value <= 0xFFFF_FF00`
<!--
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>
-->
fixes#121126
check `idx <= FieldIdx::MAX_AS_U32` before calling `FieldIdx::from_u32` to avoid panic.
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`
