| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Update cargo
12 commits in 68db37499f2de8acef704c73d9031be6fbcbaee4..64a12460708cf146e16cc61f28aba5dc2463bbb4
2025-05-22 14:27:15 +0000 to 2025-05-30 18:25:08 +0000
- chore: remove HTML comments and inline guide (rust-lang/cargo#15613)
- Add .git-blame-ignore-revs (rust-lang/cargo#15612)
- refactor: cleanup for `CompileMode` (rust-lang/cargo#15608)
- refactor: separate "global" mode from CompileMode (rust-lang/cargo#15601)
- fix(doc): pass `toolchain-shared-resources` to get doc styled (rust-lang/cargo#15605)
- fix(embedded): Resolve multiple bugs in frontmatter parser (rust-lang/cargo#15573)
- chore: Upgrade schemars (rust-lang/cargo#15602)
- Update gix & socket2 (rust-lang/cargo#15600)
- Add `-Zfix-edition` (rust-lang/cargo#15596)
- chore(toml): disable `toml`'s default features, unless necessary (rust-lang/cargo#15598)
- docs(README): fix the link to the changelog in the Cargo book (rust-lang/cargo#15597)
- Add the future edition (rust-lang/cargo#15595)
r? ghost
|
|
|
|
|
|
|
|
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
|
|
Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`
This new parameter was requested in the btree_extract_if tracking issue: https://github.com/rust-lang/rust/issues/70530#issuecomment-2486566328
I attempted to follow the style used by `Vec::extract_if`.
Before:
```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
#[unstable(feature = "btree_extract_if", issue = "70530")]
pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
where
K: Ord,
F: FnMut(&K, &mut V) -> bool;
}
```
After:
```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
#[unstable(feature = "btree_extract_if", issue = "70530")]
pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
where
K: Ord,
R: RangeBounds<K>,
F: FnMut(&K, &mut V) -> bool;
}
```
Related: #70530
—
While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
|
|
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
cargo-miri: recognize --verbose alongside -v
|
|
|
|
TB: Track permissions on the byte-level
|
|
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
Co-authored-by: Johannes Hostert <jhostert@ethz.ch>
|
|
vremyavnikuda/docs/find-all-refs-constructor-search
docs: add documentation for find_all_refs constructor search
|
|
|
|
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
|
|
Report text_direction_codepoint_in_literal when parsing
The lint is now reported in code that gets removed/modified/duplicated by macro expansion, and spans are more accurate so we don't get ICEs from trying to split a span in the middle of a character.
This removes support for lint level attributes for `text_direction_codepoint_in_literal` except at the crate level, I don't think that there's an easy way around this when the lint can be reported on code that's removed by `cfg` or that is only in the input of a macro.
Fixes #140281
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#137574 (Make `std/src/num` mirror `core/src/num`)
- rust-lang/rust#141384 (Enable review queue tracking)
- rust-lang/rust#141448 (A variety of improvements to the codegen backends)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
- rust-lang/rust#141676 (float: Disable `total_cmp` sNaN tests for `f16`)
- rust-lang/rust#141705 (Add eslint as part of `tidy` run)
- rust-lang/rust#141715 (Add `loongarch64` with `d` feature to `f32::midpoint` fast path)
- rust-lang/rust#141723 (Provide secrets to try builds with new bors)
- rust-lang/rust#141728 (Fix false documentation of FnCtxt::diverges)
- rust-lang/rust#141729 (resolve target-libdir directly from rustc)
- rust-lang/rust#141732 (creader: Remove extraenous String::clone)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Bump rustc-perf and update PGO crates
Updates rustc-perf to rust-lang/rustc-perf@8158f78f738715c060d230351623a7f7cc01bf97, and updates the crates.
r? `@Kobzol`
|
|
|
|
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
allow multiple seeds
use bitsets
fix xcompile
listened to reason and made my life so much easier
fmt
Update src/machine.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
fixups
avoid some clones
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
address review
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
fixup comment
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
address review pt 2
nit
rem fn
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
address review
unneeded unsafe
|
|
Specifically `TyAlias`, `Enum`, `Struct`, `Union`. So the fields match
the textual order in the source code.
The interesting part of the change is in
`compiler/rustc_hir/src/hir.rs`. The rest is extremely mechanical
refactoring.
|
|
Add eslint as part of `tidy` run
Rustdoc uses `eslint` to run lints on the JS files. Currently you need to run it by hand since it's not part of any `x.py` command. This PR makes it part of `test tidy`. However, to prevent having all rust developers to install `npm` and `eslint`, I made it optional: if `eslint` is not installed, then the check is simply skipped (but will tell that it is being skipped).
The second commit removes the manual checks from the docker file since `eslint` is run as part of tidy.
cc `@lolbinarycat,` [#t-rustdoc > eslint seems to only be run in CI](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/eslint.20seems.20to.20only.20be.20run.20in.20CI/with/520761477)
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#138285 (Stabilize `repr128`)
- rust-lang/rust#139994 (add `CStr::display`)
- rust-lang/rust#141571 (coretests: extend and simplify float tests)
- rust-lang/rust#141656 (CI: Add cargo tests to aarch64-apple-darwin)
Failed merges:
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix: Recognize salsa cycles in `thread_result_to_response`
|
|
|
|
Stabilize `repr128`
## Stabilisation report
The `repr128` feature ([tracking issue](https://github.com/rust-lang/rust/issues/56071)) allows the use of `#[repr(u128)]` and `#[repr(i128)]` on enums in the same way that other primitive representations such as `#[repr(u64)]` can be used. For example:
```rust
#[repr(u128)]
enum Foo {
One = 1,
Two,
Big = u128::MAX,
}
#[repr(i128)]
enum Bar {
HasThing(u16) = 42,
HasSomethingElse(i64) = u64::MAX as i128 + 1,
HasNothing,
}
```
This is the final part of adding 128-bit integers to Rust ([RFC 1504](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in #49101 back in 2018.
From a design perspective, `#[repr(u128)]`/`#[repr(i128)]` function like `#[repr(u64)]`/`#[repr(i64)]` but for 128-bit integers instead of 64-bit integers. The only differences are:
- FFI safety: as `u128`/`i128` are not currently considered FFI safe, neither are `#[repr(u128)]`/`#[repr(i128)]` enums (I discovered this wasn't the case while drafting this stabilisation report, so I have submitted #138282 to fix this).
- Debug info: while none of the major debuggers currently support 128-bit integers, as of LLVM 20 `rustc` will emit valid debuginfo for both DWARF and PDB (PDB makes use of the same natvis that is also used for all enums with fields, whereas DWARF has native support).
Tests for `#[repr(u128)]`/`#[repr(i128)]` enums include:
- [ui/enum-discriminant/repr128.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values.
- [debuginfo/msvc-pretty-enums.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct.
- [run-make/repr128-dwarf](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct.
Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`.
Closes #56071
Closes https://github.com/rust-lang/reference/issues/1368
r? lang
```@rustbot``` label +I-lang-nominated +T-lang
|
|
rustbook: Bump versions of `onig` and `onig_sys`
This fixes the build on GCC 15.
|
|
Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
r? `@fee1-dead`
|
|
Use `builtin_index` instead of hand-rolling it
Just using the dedicated method more
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
|
|
|
|
fix comment in before_stack_pop
|
|
|
|
|
|
|
|
|
|
This fixes the build on GCC 15
|
