| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Clippy subtree update
r? `@Manishearth`
|
|
The Rust source code previously mised ProjectJson and JsonProject,
and the TypeScript definition didn't match either.
Use 'ProjectJson' everywhere. This is purely an internal change.
|
|
Produce ClosureBinder node in atom.rs
|
|
r=albertlarsan68,jieyouxu,mark-simulacrum,kobzol,jyn514,Noratrieb,WaffleLapkin,RalfJung,bjorn3
redesign stage 0 std
### Summary
**Blog post: https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/**
This PR changes how bootstrap builds the stage 1 compiler by switching to precompiled stage 0 standard library instead of building the in-tree one. The goal was to update bootstrap to use the beta standard library at stage 0 rather than compiling it from source (see the motivation at https://github.com/rust-lang/compiler-team/issues/619).
Previously, to build a stage 1 compiler bootstrap followed this path:
```
download stage0 compiler -> build in-tree std -> compile stage1 compiler with in-tree std
```
With this PR, the new path is:
```
download stage0 compiler -> compile stage1 compiler with precompiled stage0 std
```
This also means that `cfg(bootstrap)`/`cfg(not(bootstrap))` is no longer needed for library development.
### Building "library"
Since stage0 `std` is no longer in-tree `x build/test/check library --stage 0` is now no-op. The minimum supported stage to build `std` is now 1. For the same reason, default stage values in the library profile is no longer 0.
Because building the in-tree library now requires a stage1 compiler, I highly recommend library developers to enable `download-rustc` to speed up compilation time.
<hr>
**Blog post: https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/**
If you encounter a bug or unexpected results please open a topic in the [#t-infra/bootstrap](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap) Zulip channel or create a [bootstrap issue](https://github.com/rust-lang/rust/issues/new?template=bootstrap.md).
(Review thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Review.20thread.3A.20stage.200.20redesign.20PR/with/508271433)
~~Blocked on https://github.com/rust-lang/rust/pull/122709~~
try-job: dist-x86_64-linux
try-job: `x86_64-msvc*`
try-job: `x86_64-apple-*`
try-job: `aarch64-apple`
try-job: x86_64-gnu
try-job: `x86_64-gnu-llvm*`
|
|
I find it much easier to think about in the positive sense.
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140370 (Improve diagnostics for usage of qualified paths within tuple struct exprs/pats)
- rust-lang/rust#141224 (terminology: allocated object → allocation)
- rust-lang/rust#141622 (implement `va_arg` for `powerpc`)
- rust-lang/rust#141666 (source_span_for_markdown_range: fix utf8 violation)
- rust-lang/rust#141789 (Exclude `CARGO_HOME` from `generate-copyright` in-tree determination)
- rust-lang/rust#141823 (Drive-by refactor: use `OnceCell` for the reverse region SCC graph)
- rust-lang/rust#141834 (Add unimplemented `current_dll_path()` for WASI)
- rust-lang/rust#141846 (Fix TLS model on bootstrap for cygwin)
- rust-lang/rust#141852 (resolve if-let-chain FIXME on bootstrap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
ferrocene:hoverbear/exclude-cargo-home-from-in-tree-consideration, r=clubby789
Exclude `CARGO_HOME` from `generate-copyright` in-tree determination
On Ferrocene, we noticed that in our releases the out-of-tree notices were not being included. When `x.py run generate-copyright` was ran on local development machines, it worked fine.
After some investigations ``@tshepang`` and I determined that the problem was that the cargo registry (located in `CARGO_HOME`) started with the source directory on CI jobs, and was being excluded by this line:
https://github.com/rust-lang/rust/blob/15825b7161f8bd6a3482211fbf6727a52aa1166b/src/tools/generate-copyright/src/cargo_metadata.rs#L85-L88
In Ferrocene's `run.sh` we set `CARGO_HOME` to be `build/cargo-home`: https://github.com/ferrocene/ferrocene/blob/96a45dd9a18c6e54d3cd81750a78fe459fa48af0/ferrocene/ci/run.sh#L34-L46 which caused this issue.
This PR passes the `CARGO_HOME` variable to the `generate-copyright` tool and expands the consideration of in-tree-ness to be aware of `CARGO_HOME`. It is an upstreaming of https://github.com/ferrocene/ferrocene/pull/1491.
## Testing
Run `CARGO_HOME=build/cargo-home ./x.py run generate-copyright` on `master`, then check `build/host/doc/COPYRIGHT` and look for out of tree dependencies (at the bottom).
Then, try running the same command in this branch.
|
|
|
|
Tokio `AsyncWriteExt::write` doesn't actually ensure that the contents
have written, it just *starts* the write operation. To ensure that the
file has actually been written, we need to `sync_all` first.
|
|
The test did `write` and `read` and hoped that it would read/write
everything, which doesn't always happen and caused CI failures.
Switch to `write_all` and `read_to_end` to make it more reliable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and on visibility
|
|
Add `const` support for float rounding methods
# Add `const` support for float rounding methods
This PR makes the following float rounding methods `const`:
- `f64::{floor, ceil, trunc, round, round_ties_even}`
- and the corresponding methods for `f16`, `f32` and `f128`
Tracking issue: https://github.com/rust-lang/rust/issues/141555
## Procedure
I followed https://github.com/rust-lang/rust/commit/c09ed3e767a73d83673790f74c357432fa44d320 as closely as I could in making float methods `const`, and also received great guidance from https://internals.rust-lang.org/t/const-rounding-methods-in-float-types/22957/3?u=ruancomelli.
## Note
This is my first code contribution to the Rust project, so please let me know if I missed anything - I'd be more than happy to revise and learn more. Thank you for taking the time to review it!
|
|
Stabilize feature `result_flattening`
Stabilizes the `Result::flatten` method
## Implementations
- [x] Implementation `Result::flatten`: https://github.com/rust-lang/rust/pull/70140
- [x] Implementation `const` `Result::flatten`: https://github.com/rust-lang/rust/pull/130692
- [x] Update stabilization attribute macros (this PR)
## Stabilization process
- [x] Created this PR [suggested](https://github.com/rust-lang/rust/issues/70142#issuecomment-2885044548) by ``@RalfJung``
- [x] FCP (haven't found any, is it applicable here?)
- [ ] Close issue rust-lang/rust#70142
|
|
Add const support for the float rounding methods floor, ceil, trunc,
fract, round and round_ties_even.
This works by moving the calculation logic from
src/tools/miri/src/intrinsics/mod.rs
into
compiler/rustc_const_eval/src/interpret/intrinsics.rs.
All relevant method definitions were adjusted to include the `const`
keyword for all supported float types: f16, f32, f64 and f128.
The constness is hidden behind the feature gate
feature(const_float_round_methods)
which is tracked in
https://github.com/rust-lang/rust/issues/141555
This commit is a squash of the following commits:
- test: add tests that we expect to pass when float rounding becomes const
- feat: make float rounding methods `const`
- fix: replace `rustc_allow_const_fn_unstable(core_intrinsics)` attribute with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
- revert: undo update to `library/stdarch`
- refactor: replace multiple `float_<mode>_intrinsic` rounding methods with a single, parametrized one
- fix: add `#[cfg(not(bootstrap))]` to new const method tests
- test: add extra sign tests to check `+0.0` and `-0.0`
- revert: undo accidental changes to `round` docs
- fix: gate `const` float round method behind `const_float_round_methods`
- fix: remove unnecessary `#![feature(const_float_methods)]`
- fix: remove unnecessary `#![feature(const_float_methods)]` [2]
- revert: undo changes to `tests/ui/consts/const-eval/float_methods.rs`
- fix: adjust after rebase
- test: fix float tests
- test: add tests for `fract`
- chore: add commented-out `const_float_round_methods` feature gates to `f16` and `f128`
- fix: adjust NaN when rounding floats
- chore: add FIXME comment for de-duplicating float tests
- test: remove unnecessary test file `tests/ui/consts/const-eval/float_methods.rs`
- test: fix tests after upstream simplification of how float tests are run
|
|
Hir item kind field order
A follow-up to rust-lang/rust#141675.
r? `@fee1-dead`
|
|
fix: Fix manual not containing diagnostics documentation
|
|
|
|
|
|
|
|
Remove useless file
|
|
|
|
refactor: Remove unncessary duplication in highlight_related
|
|
|
|
|
|
|
|
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?
|
