| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
- `slice::sort` -> driftsort
https://github.com/Voultapher/sort-research-rs/blob/main/writeup/driftsort_introduction/text.md
- `slice::sort_unstable` -> ipnsort
https://github.com/Voultapher/sort-research-rs/blob/main/writeup/ipnsort_introduction/text.md
Replaces the sort implementations with tailor made ones that strike a
balance of run-time, compile-time and binary-size, yielding run-time and
compile-time improvements. Regressing binary-size for `slice::sort`
while improving it for `slice::sort_unstable`. All while upholding the
existing soft and hard safety guarantees, and even extending the soft
guarantees, detecting strict weak ordering violations with a high chance
and reporting it to users via a panic.
In addition the implementation of `select_nth_unstable` is also adapted
as it uses `slice::sort_unstable` internals.
|
|
Refactor examples and enhance documentation in result.rs
- Replaced `map` with `map_err` in the error handling example for correctness
- Reordered example code to improve readability and logical flow
- Added assertions to examples to demonstrate expected outcomes
|
|
r=fmease
Include line tables in compiler profile
This profile has only undergone minimal tweaks since it was originally drafted. I asked a number of compiler contributors and they said they set rust.debug explicitly. This was even true for one contributor that set `rust.debug = false`! Almost everyone seems slightly surprised that `rust.debug = true` is not the default.
However, adding full debuginfo at this level costs multiple gigabytes! We can still get much better profiling and such by setting `rust.debuginfo-level = "line-tables-only"` at the cost of only 150~200 MB on the weight of a fresh build dir from `./x.py check`.
|
|
This profile has only undergone minimal tweaks since it was originally
drafted. I asked a number of compiler contributors and they said they
set rust.debug explicitly. This was even true for one contributor that
set `rust.debug` = false! Almost everyone seems slightly surprised that
`rust.debug = true` is not the default.
However, adding full debuginfo at this level costs multiple gigabytes!
We can still get much better debuginfo by setting "line-tables-only"
at the cost of only 150~200 MB.
|
|
workingjubilee:macro-metavar-expr-with-a-shorter-len, r=c410-f3r,joshtriplett,joshtriplett
Rename `${length()}` to `${len()}`
Implements the rename suggested in https://github.com/rust-lang/rust/pull/122808#issuecomment-2047722187
> I brought this up in the doc PR but it belongs here – `length` should probably be renamed `len` before stabilization. The latter is de facto standard in the standard library, whereas the former is only used in a single unstable API. These metafunctions aren’t library items of course, but should presumably still be consistent with established names.
r? `@c410-f3r`
|
|
Rollup of 5 pull requests
Successful merges:
- #125003 (avoid using aligned_alloc; posix_memalign is better-behaved)
- #125142 (Migrate `run-make/rustdoc-themes` to new rmake.rs)
- #125146 (Migrate `run-make/panic-impl-transitive` to `rmake`)
- #125154 (Small improvements to the documentaion of FnAbi )
- #125159 (Meta: Allow unauthenticated users to modify `L-*`, `PG-*` and `-Z*` labels)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Meta: Allow unauthenticated users to modify `L-*`, `PG-*` and `-Z*` labels
Complements: rust-lang/rust-forge#744.
1. `L-*`: Issues and PRs concerning specific lints
2. `PG-*`: Issues and PRs concerning specific project groups
3. `-Z*`: Issues and PRs concerning specific unstable `-Z` compiler options
These are safe to expose. Allows unauthenticated users greater leeway in triaging issues.
We have a lot of such people <3 and I want to support them as much as possible.
r? jieyouxu (you get assigned a lot these days :P) or compiler
|
|
Small improvements to the documentaion of FnAbi
I have updated the documentation of `FnAbi`.
The `arg` and `ret` fields are no longer LLVM types, but Rust types(`ArgAbi` contains a `TyAndLayout` and a `PassMode`), so I changed the documentation to reflect that.
Besides that, I also added documentation to other fields, and added a clarification about the differences between `FnAbi` and `FnSig`, since this is not something that is immediately obvious.
|
|
Migrate `run-make/panic-impl-transitive` 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).
The test itself is quite simple, but the "handle panics by entering infinite loop" part is strange.
|
|
Migrate `run-make/rustdoc-themes` to new rmake.rs
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
avoid using aligned_alloc; posix_memalign is better-behaved
Also there's no reason why wasi should be different than all the other Unixes here.
|
|
|
|
|
|
r=fmease
rustdoc: Negative impls are not notable
In #124097, we add `impl !Iterator for [T]` for coherence reasons, and since `Iterator` is a [notable trait](https://github.com/rust-lang/rust/blob/8387315ab3c26a57a1f53a90f188f0bc88514bca/library/core/src/iter/traits/iterator.rs#L40), this means that all `-> &[_]` now are tagged with a `!Iterator` impl as a notable trait.
I "fixed" the failing tests in that PR with 6cbbb8b709a43482847243484ed67131e372ba71, where I just blessed the tests, since I didn't want to mix these changes with that PR; however, don't believe negative impls are notable, and this PR aims to prevent these impls from being mentioned.
In the standard library, we use negative impls purely to guide coherence. They're not really a signal of anything useful to the end-user. If there ever is a case that we want negative impls to be mentioned as notable, this really should be an opt-in feature.
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #124307 (Optimize character escaping.)
- #124975 (Use an helper to move the files)
- #125027 (Migrate `run-make/c-link-to-rust-staticlib` to `rmake`)
- #125038 (Invert comparison in `uN::checked_sub`)
- #125104 (Migrate `run-make/no-cdylib-as-rdylib` to `rmake`)
- #125137 (MIR operators: clarify Shl/Shr handling of negative offsets)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
MIR operators: clarify Shl/Shr handling of negative offsets
"made unsigned" was not fully clear (made unsigned how? by using `abs`? no), so let's say "re-interpreted as an unsigned value of the same size" instead.
r? `@scottmcm`
|
|
Migrate `run-make/no-cdylib-as-rdylib` 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).
> "the test will fail if the cdylib is picked, because it doesn't export any rust symbols"
Is that true? Is there a way to verify?
I suggest maybe extending the test with: (after cleaning the directory)
```rust
rustc()
.input("bar.rs")
.crate_type("cdylib")
.run();
rustc()
.input("foo.rs")
.prefer_dynamic()
.run();
fail();
```
to make sure we're actually testing something here.
|
|
Invert comparison in `uN::checked_sub`
After #124114, LLVM no longer combines the comparison and subtraction in `uN::checked_sub` when either operand is a constant (demo: https://rust.godbolt.org/z/MaeoYbsP1). The difference is more pronounced when the expression is slightly more complex (https://rust.godbolt.org/z/4rPavsYdc).
This is due to the use of `>=` here:
https://github.com/rust-lang/rust/blob/ee97564e3a9f9ac8c65103abb37c6aa48d95bfa2/library/core/src/num/uint_macros.rs#L581-L593
For constant `C`, LLVM eagerly converts `a >= C` into `a > C - 1`, but the backend can only combine `a < C` with `a - C`, not `C - 1 < a` and `a - C`: https://github.com/llvm/llvm-project/blob/e586556e375fc5c4f7e76b5c299cb981f2016108/llvm/lib/CodeGen/CodeGenPrepare.cpp#L1697-L1742
This PR[^1] simply inverts the `>=` into `<` to restore the LLVM magic, and somewhat align this with the implementation of `uN::overflowing_sub` from #103299.
When the result is stored as an `Option` (rather than being branched/cmoved on), the discriminant is `self >= rhs`. This PR doesn't affect the codegen (and relevant tests) of that since LLVM will negate `self < rhs` to `self >= rhs` when necessary.
[^1]: Note to `self`: My very first contribution to publicly-used code. Hopefully like what I should learn to always be, tiny and humble.
|
|
Migrate `run-make/c-link-to-rust-staticlib` to `rmake`
Part of #121876.
r? `@jieyouxu`
|
|
Use an helper to move the files
In case the source is not in the same filesystem.
See https://github.com/openwrt/packages/commit/c1b3e0440f67bcec101a3f72525f9c90eb4e6497#commitcomment-141886468
|
|
Optimize character escaping.
Allow optimization of panicking branch in `EscapeDebug`, see https://github.com/rust-lang/rust/pull/121805.
r? `@joboet`
|
|
Co-authored-by: joboet <jonasboettiger@icloud.com>
|
|
delegation: Implement list delegation
```rust
reuse prefix::{a, b, c};
```
Using design described in https://github.com/rust-lang/rfcs/pull/3530#issuecomment-2020869823 (the lists are desugared at macro expansion time).
List delegations are expanded eagerly when encountered, similarly to `#[cfg]`s, and not enqueued for later resolution/expansion like regular macros or glob delegation (https://github.com/rust-lang/rust/pull/124135).
Part of https://github.com/rust-lang/rust/issues/118212.
|
|
|
|
|
|
Make crashes dump mir to build dir
Set `-Zdump-mir-dir` for `crashes`-style tests.
Alternatively, we just remove `tests/crashes/124436.rs`, since if the only way to get it to repro is via `-Zdump-mir`, then maybe it's not worth it to fix.
Fixes #125029
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #124990 (Also expand weak alias tys inside consts inside `expand_weak_alias_tys`)
- #125108 (coverage: `CoverageIdsInfo::mcdc_bitmap_bytes` is never needed)
- #125132 (Add `on_unimplemented" typo suggestions)
- #125135 (Fix the dedup error because of spans from suggestion)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix the dedup error because of spans from suggestion
Fixes #116502
I believe this kind of issue is supposed resolved by #118057, but the `==` in `span` respect syntax context, here we should only care that they point to the same bytes of source text, so should use `source_equal`.
|
|
Add `on_unimplemented" typo suggestions
|
|
coverage: `CoverageIdsInfo::mcdc_bitmap_bytes` is never needed
This code for recalculating `mcdc_bitmap_bytes` in a query doesn't provide any benefit, because its result won't have changed from the value in `FunctionCoverageInfo` that was computed during the MIR instrumentation pass.
Extracted from #124571, to avoid having this held up by unrelated issues with condition count checks.
`@rustbot` label +A-code-coverage
|
|
r=compiler-errors
Also expand weak alias tys inside consts inside `expand_weak_alias_tys`
Ever since #121344 has been merged, I couldn't let go of the fear that I might've slipped a tiny bug into rustc (:P).
Checking the type flags of the `Const` is strictly more correct than only checking the ones of the `Const`'s `Ty`. I don't think it's possible to trigger an ICE rn (i.e., one of the two `bug!("unexpected weak alias type")` I added in branches where `expand_weak_alias_tys` should've expanded *all* weak alias tys) because presently const exprs aren't allowed to capture late-bound vars. To be future-proof however, we should iron this out.
A possible reproducer would be the following if I'm not mistaken (currently fails to compile due to the aforementioned restriction):
```rs
#![feature(lazy_type_alias, adt_const_params, generic_const_exprs)]
type F = for<'a> fn(A<{ S::<Weak<'a>>(loop {}) }>) -> &'a ();
type A<const N: S<Weak<'static>>> = ();
#[derive(PartialEq, Eq, std::marker::ConstParamTy)]
struct S<T>(T);
type Weak<'a> = &'a ();
```
Whether a late-bound region should actually be considered constrained by a const expr is a separate question — one which we don't need to answer until / unless we actually allow them in such contexts (probable answer: only inside the return exprs of a block but not inside the stmts).
r? oli-obk (he's not available rn but that's fine) or types or compiler
|
|
|
|
Migrate `run-make/issue-11908` to new `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Set as draft, because I have a few concerns:
- [x] I am not sure if `target().contains("darwin")` is a good way of checking that the target is on OSX.
- [x] I find it strange that the `dylib` part of the test adapts to different target platforms, but not the `rlib` part. Is `rlib` named the same on all platforms?
|
|
|
|
|
|
`rustc_hir_typeck`: Account for `skipped_ref_pats` in `expr_use_visitor`
Fixes #125058
r? `@Nadrieril`
cc https://github.com/rust-lang/rust/issues/123076
`@rustbot` label A-edition-2024 A-patterns
|
|
```rust
reuse prefix::{a, b, c}
```
|
|
|
|
|
|
|
|
|
|
|
|
r=Mark-Simulacrum
feat(tools/opt-dist): allow local builds to specify a rustc-perf checkout
This is a first step towards allowing `opt-dist` to work in a sandboxed /
air-gapped environment, as it allows users to bypass the ad-hoc download of
`rustc-perf`.
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #119838 (style-guide: When breaking binops handle multi-line first operand better)
- #124844 (Use a proper probe for shadowing impl)
- #125047 (Migrate `run-make/issue-14500` to new `rmake.rs` format)
- #125080 (only find segs chain for missing methods when no available candidates)
- #125088 (Uplift `AliasTy` and `AliasTerm`)
- #125100 (Don't do post-method-probe error reporting steps if we're in a suggestion)
- #125118 (Use new utility functions/methods in run-make tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
