Minor internal comments fix for `BufRead::read_line`
Just a little fix that came up while I was reading through this source code, and had to search for a few minutes to find out what was actually *meant* here.
Closes#13306Closes#9925Closes#9470Closes#9305
Clippy gives wrong suggestions when the key is not `Copy`. As suggested
in #9925, in such cases Clippy will simply warn but no fix.
changelog: [`map_entry`]: fix wrong suggestions when key is not `Copy`
- UEFI device path is a series of nodes layed out in a contiguous memory
region. So it makes sense to use Iterator abstraction for modeling
DevicePaths
- This PR has been split off from #135368 for easier review. The allow
dead_code will be removed in #135368
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
This field in the server capabilities instructs the client to maintain
the diagnostics received from a `textDocument/diagnostic` pull request
as a separate set from other diagnostics: namely those sent with classic
"push" diagnostics, `textDocument/publishDiagnostic`. rust-analyzer
emits "native" diagnostics (computed by rust-analyzer itself) in pull
diagnostics and separately emits cargo-based diagnostics with push, so
push and pull diagnostics should be different sets. Setting this field
instructs the client to avoid clearing push diagnostics when new pull
diagnostics arrive and vice versa.
`librustdoc`: return `impl fmt::Display` in more places instead of writing to strings
Continuation of #136784 , another attempt at landing the larger parts of #136748 .
I'd like to, gradually, make all of the building blocks for rendering docs in `librustdoc` return `impl fmt::Display` instead of returning `Strings`, or receiving a `&mut String` (or `&mut impl fmt::Write`). Another smaller end goal is to be able to get rid of [`write_str`](8dac72bb1d/src/librustdoc/html/format.rs (L40-L42)).
This PR is a large step in that direction.
Most of the changes are quite mechanical, and split up into separate commits for easier reviewing (hopefully). I took `print_item` and then started by converting all the functions it called (and their dependencies), and the last commit does the conversion for `print_item` itself. Ignoring whitespace should make reviewing a bit easier.
And most importantly, perf run shows pretty good results locally, hopefully CI will also show green 😁
r? `@GuillaumeGomez` , if you feel like it.
A lot of the magic constants can be turned into expressions. This
reduces some code duplication.
Additionally, add traits to make these operations fully generic. This
will make it easier to support `f16` and `f128`.
Rewrite the `ci.py` script in Rust
It would seem that I would learn by now that any script written in Python will become unmaintainable sooner or later, but alas..
r? `@marcoieni`
try-job: aarch64-gnu
try-job: dist-x86_64-linux-alt
try-job: x86_64-msvc-ext2
Fixes: https://github.com/rust-lang/rust/issues/137013
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler,
which is clearly not what we requested. This doesn't happen when running `x build --stage N`
without explicitly targeting the compiler.
The changes applied fix this issue.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
The previous commit renamed `Decimal` to `DecimalSeq`. Now, rename the
type that represents a decimal floating point number to be `Decimal`.
Additionally, add some tests for internal behavior.
This module currently contains two decimal types, `Decimal` and
`Number`. These names don't provide a whole lot of insight into what
exactly they are, and `Number` is actually the one that is more like an
expected `Decimal` type.
In accordance with this, rename the existing `Decimal` to `DecimalSeq`.
This highlights that it contains a sequence of decimal digits, rather
than representing a base-10 floating point (decimal) number.
Additionally, add some tests to validate internal behavior.
Currently, test case generators are launched in parallel and their test
cases also run in parallel, all within the same pool. I originally
implemented this with the assumption that there would be an advantage in
parallelizing the generators themselves, but this turns out to not
really have any benefit.
Simplify things by running generators in series while keeping their test
cases parallelized. This makes the code easier to follow, and there is
no longer a need for MPSC or multiprogress bars. Additionally, the UI
output can be made cleaner.
Rollup of 10 pull requests
Successful merges:
- #137804 (rename BackendRepr::Vector → SimdVector)
- #137807 (Fully qualify `Result` in generated doctest code)
- #137809 (Use correct error message casing for `io::const_error`s)
- #137818 (tests: adapt for LLVM 21 changes)
- #137822 (Update query normalizer docs to not position it as the greatest pioneer in the space of normalization)
- #137824 (Tweak invalid RTN errors)
- #137828 (Fix inaccurate `std::intrinsics::simd` documentation)
- #137830 (Fix link failure on AVR (incompatible ISA error))
- #137837 (Update `const_conditions` and `explicit_implied_const_bounds` docs)
- #137840 (triagebot: only ping me for constck)
r? `@ghost`
`@rustbot` modify labels: rollup
LLVM has crashes at some `half` operations when built with assertions
enabled if fp-armv8 is not available [1]. Things seem to usually work,
but we are reaching LLVM undefined behavior so this needs to be
disabled.
[1]: https://github.com/llvm/llvm-project/issues/129394
Clippy subtree update
? `@Manishearth`
Cargo.lock change because of Clippy version bump and rustc_tool_utils new release.
Fixes#137640
Would be nice, if we could this merged before nightly is being build, so that this ICE is fixed tomorrow.
