| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#141072 (Stabilize feature `result_flattening`)
- rust-lang/rust#141215 (std: clarify Clone trait documentation about duplication semantics)
- rust-lang/rust#141277 (Miri CI: test aarch64-apple-darwin in PRs instead of the x86_64 target)
- rust-lang/rust#141521 (Add `const` support for float rounding methods)
- rust-lang/rust#141812 (Fix "consider borrowing" for else-if)
- rust-lang/rust#141832 (library: explain TOCTOU races in `fs::remove_dir_all`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This actually fixes a bug where before only 20 arguments could be passed. As far as I can tell, an arbitrary number of arguments is now supported
|
|
Fix "consider borrowing" for else-if
Fixes rust-lang/rust#141810
When trying to suggest a borrow on a `if` or `block` expression, instead we now recurse into the `if` or `block`.
The comments in the code should explain the goal of the new code.
r? ``@jdonszelmann``
|
|
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
|
|
`slice.get(i)` should use a slice projection in MIR, like `slice[i]` does
`slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.
This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement. (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.)
I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition. Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata. But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`. Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.
Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
|
|
it is non-trivial to reproduce this bug through rustdoc,
which uses this function less than clippy,
so the regression test was added as a unit test
instead of an integration test.
|
|
|
|
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
|
|
Enable non-leaf Frame Pointers for mingw-w64 Arm64 Windows
Based on https://github.com/rust-lang/rust/pull/140828
I don't have AArch64 Windows to test it, but I trust LLVM to handle it well.
|
|
Hir item kind field order
A follow-up to rust-lang/rust#141675.
r? `@fee1-dead`
|
|
Note expr being cast when encounter NonScalar cast error
Fixes #140491
I added note for `expr` so that it doesn't treat `&x as T` as `&(x as T)` but `(&x) as T`. But I'm not sure if I want to add note for all NonScalar, maybe for specific `expr_ty`?
r? compiler
|
|
|
|
|
|
gold has been deprecated recently and is known to behave incorrectly
around Rust programs, including miscompiling `#[used(linker)]`.
Tell people to switch to a different linker instead.
Co-Authored-By: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
This obviously doesn't work when cross-compiling from Linux.
Split out from: https://github.com/rust-lang/rust/pull/140772
|
|
|
|
Add fast path for maybe-initializedness in liveness
r? `@matthewjasper`
Correct me if I'm wrong Matthew, but my understanding is that
1. `MaybeInitializedPlaces` is currently eagerly computed, in `do_mir_borrowck`
2. but this data is only used in liveness
3. and `liveness::trace` actually only uses it for drop-liveness
This PR moves the computation to `liveness::trace` which looks to be its only use-site. We also add a fast path there, so that it's only computed by drop-liveness.
This is interesting because 1) liveness is only computed for relevant live locals, 2) drop-liveness is only computed for relevant live locals with >0 drop points; 0 is the common case from our benchmarks, as far as I can tell, so even just computing the entire data lazily helps.
It seems possible to also reduce the domain here, and speed up the analysis for the cases where it has to be computed -- so I've left a fixme for that, and may look into it soon.
(I've come upon this while doing implementation work for polonius, so don't be too enamored with possible wins: the goal is to reduce the eventual polonius overhead and make it more palatable 😓)
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
r=compiler-errors
Fix spans for unsafe binders
closes rust-lang/rust#141758
r? ``@compiler-errors``
|
|
mir-opt: Do not transform non-int type in match_branches
Fixes #141378.
r? mir-opt
|
|
Fix the issue of typo of comma in arm parsing
Fixes #140991
I also checked is it a '/', since it's near from ',' from keyboard.
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
|
|
rustc_codegen_llvm: use `threadlocal.address` intrinsic to access TLS
Fixes #136044
r? `@nikic`
|
|
|
|
|
|
|
|
Noratrieb:RUSTC_ACTUALLY_DO_NOT_RETRY_LINKER_ON_SEGFAULT, r=petrochenkov
Remove RUSTC_RETRY_LINKER_ON_SEGFAULT hack
It looks like this was added in rust-lang/rust#40422 6 years ago because of issues with the MacOS linker. MacOS got a new linker in the meantime, so that should probably be resolved now. Hopefully.
r? petrochenkov
|
|
Add tls_model for cygwin and enable has_thread_local
I've also tried to set `has_thread_local` to `true` and found it works actually. Why do we still implement our own `thread_local` instead of delegating all of them to LLVM?
cc: `@jeremyd2019`
|
|
Structurally normalize types as needed in `projection_ty_core`
Introduce a `structurally_normalize` callback to `projection_ty_core`, and then use it before we match on the ty kind in `projection_ty_core`.
Previously we were only structurally normalizing the return type of the `handle_field` struct, but if we were to (e.g.) apply a deref projection to that type, then the resulting type is not guaranteed to be structurally normalized and any subsequent projections applied would ICE.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/221
I'll leave a few comments inline to explain the changes.
r? lcnr
---
Also fixes rust-lang/rust#141708
|
|
|
|
|
|
|
|
This avoids having to get the function signature.
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#133823 (Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion)
- rust-lang/rust#141004 (Report text_direction_codepoint_in_literal when parsing)
- rust-lang/rust#141407 (Refactor the two-phase check for impls and impl items)
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141507 (atomic_load intrinsic: use const generic parameter for ordering)
- rust-lang/rust#141538 (implement `va_arg` for x86_64 systemv)
- rust-lang/rust#141669 (float: Replace some approximate assertions with exact)
- rust-lang/rust#141747 (rustdoc: display doc(cfg(false)) properly)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
implement `va_arg` for x86_64 systemv
tracking issue: https://github.com/rust-lang/rust/issues/44930
Turns out LLVM's `va_arg` is also unreliable for this target.
https://github.com/llvm/llvm-project/issues/141361
So, like clang, we implement our own. I used
- the spec at https://gitlab.com/x86-psABIs/x86-64-ABI
- the clang implementation at https://github.com/llvm/llvm-project/blob/9a440f84773c56d3803f330774acb2b4f471d5b4/clang/lib/CodeGen/Targets/X86.cpp#L3041
We can take a bunch of shortcuts because the return type of `va_list` must implement `VaArgSafe`. I also extended some of the tests, because up to 11 floats can be stored in the `reg_safe_area` for this calling convention.
r? `@workingjubilee`
`@rustbot` label +F-c_variadic
try-job: x86_64-apple-1
|
|
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?
|
|
remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`
`visit_clobber` is not really useful except for one niche purpose
involving generic code. We should just use the replace logic where we
can.
|
|
Refactor the two-phase check for impls and impl items
Refactor the two-phase dead code check to make the logic clearer and simpler:
1. adding assoc fn and impl into `unsolved_items` directly during the initial construction of the worklist
2. converge the logic of checking whether assoc fn and impl are used to `item_should_be_checked`, and the item is considered used only when its corresponding trait and Self adt are used
This PR only refactors as much as possible to avoid affecting the original functions. However, due to the adjustment of the order of checks, the test results are slightly different, but overall, there is no regression problem
Fixes rust-lang/rust#127911
Fixes rust-lang/rust#128839
Extracted from https://github.com/rust-lang/rust/pull/128637.
r? petrochenkov
try-job: dist-aarch64-linux
|
|
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
|
|
Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion
In rust-lang/rust#138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix rust-lang/rust#56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused `extern crate`
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
|
```
r? `@petrochenkov`
try-job: x86_64-gnu-aux
|
|
Make some assertions in solver into debug assertions
These may or may not be expensive :>
r? lcnr
|
|
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
|
|
It looks like this was added 6 years ago because of issues with the
MacOS linker. MacOS got a new linker in the meantime, so that should
probably be resolved now. Hopefully.
|
|
|
|
Turns out LLVM's `va_arg` is also unreliable for this target, so we need
our own implementation.
|
