| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Computed by diffing of:
$ rg "[ ]+@FEATURE: .*: \"(.*)\";" -r '$1' --no-filename \
crates/std_detect/src/detect/ | sort | uniq
With (from the main Rust repo[^1]):
$ rg "target_feature" tests/ui/check-cfg/well-known-values.stderr
[^1]: https://github.com/rust-lang/rust/blob/e8c698bb3bdc121ac7f65919bd16d22f6567a3f1/tests/ui/check-cfg/well-known-values.stderr#L177
|
|
This is necessary to avoid `unexpected_cfgs` warnings for unexpected/
missing target features, in user code.
|
|
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes #102246
|
|
|
|
unpin and update memchr
I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by https://github.com/rust-lang/rust/pull/129079
Fixes #127890
|
|
fix `LazyLock::get` and `LazyLock::get_mut` document
|
|
Implement `div_ceil` for `NonZero<unsigned>`
ACP: https://github.com/rust-lang/libs-team/issues/471
|
|
|
|
Inline str::repeat
`str` is non-generic and `str.repeat()` doesn't get inlined, which makes it use a slower algorithm in case of 1-char repetitions. Equivalent byte slice does get inlined: https://rust.godbolt.org/z/4arvh97r4
|
|
Signed-off-by: Xinye <xinye.tao@metabit-trading.com>
|
|
Revert using `HEAP` static in Windows alloc
Fixes #131468
This does the minimum to remove the `HEAP` static that was causing chromium issues. It would be worth having a more substantial look at this module but for now I think this addresses the immediate issue.
cc `@danakj`
|
|
|
|
approved by t-libs: https://github.com/rust-lang/libs-team/issues/475#issuecomment-2457858458
|
|
|
|
Previous changes in Rust and LLVM have caused stdarch to be broken in
debug, so add testing to ensure that this is caught.
|
|
|
|
Fix an extra newline in rendered std doc
Fixes #132564
(taken from the issue above)
The problem with the formatting is due to that newline between `<code>` and `<svg>`. Any newlines outside of the code (i.e., within elements inside of it) are fine.
|
|
Add new unstable feature `const_eq_ignore_ascii_case`
Tracking issue - #131719
Mark `[u8]`, `str` `eq_ignore_ascii_case` functions const
---
The codegen for this implementation matches the existing `iter::zip` implementation better than incrementing with a counter
while loop with counter - https://rust.godbolt.org/z/h9cs5zajc
while let - https://rust.godbolt.org/z/ecMeMjjEb
|
|
The new `is_ascii` function is optimized to use the
`pmovmskb` vector instruction which tests the high bit in a lane.
This corresponds to the same check of whether a byte is ASCII so
ASCII validity checking can be vectorized. This instruction
does not exist on other platforms so it is likely to regress performance
and is gated to all(target_arch = "x86_64", target_feature = "sse2").
Add codegen test
Remove crate::mem import for functions included in the prelude
|
|
make char::is_whitespace unstably const
I am adding this to the existing https://github.com/rust-lang/rust/issues/132241 feature gate, since `is_digit` and `is_whitespace` seem similar enough that one can group them together.
|
|
Add LONG benchmarks for more comparison between the methods
|
|
Mark `[u8]`, `str` `eq_ignore_ascii_case` functions const
|
|
Rollup of 5 pull requests
Successful merges:
- #131261 (Stabilize `UnsafeCell::from_mut`)
- #131405 (bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip)
- #132077 (Add a new `wide-arithmetic` feature for WebAssembly)
- #132562 (Remove the `wasm32-wasi` target from rustc)
- #132660 (Remove unused errs.rs file)
Failed merges:
- #131721 (Add new unstable feature `const_eq_ignore_ascii_case`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fixes #132564
|
|
Stabilize `UnsafeCell::from_mut`
Closes #111645.
FCP: https://github.com/rust-lang/rust/issues/111645#issuecomment-2393893003
Note that because `const_mut_refs` and `const_refs_to_cell` was stabilized, it's okay to const-stabilize this method as well.
|
|
Rollup of 8 pull requests
Successful merges:
- #132259 (rustc_codegen_llvm: Add a new 'pc' option to branch-protection)
- #132409 (CI: switch 7 linux jobs to free runners)
- #132498 (Suggest fixing typos and let bindings at the same time)
- #132524 (chore(style): sync submodule exclusion list between tidy and rustfmt)
- #132567 (Properly suggest `E::assoc` when we encounter `E::Variant::assoc`)
- #132571 (add const_eval_select macro to reduce redundancy)
- #132637 (Do not filter empty lint passes & re-do CTFE pass)
- #132642 (Add documentation on `ast::Attribute`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
add const_eval_select macro to reduce redundancy
I played around a bit with a macro to make const_eval_select invocations look a bit nicer and avoid repeating the argument lists. Here's what I got. What do you think?
I didn't apply this everywhere yet because I wanted to gather feedback first.
The second commit moves the macros from https://github.com/rust-lang/rust/pull/132542 into a more sensible place. It didn't seem worth its own PR and would conflict with this PR if done separately.
Cc ``@oli-obk`` ``@saethlin`` ``@tgross35``
try-job: dist-aarch64-msvc
|
|
[core/fmt] Replace checked slice indexing by unchecked to support panic-free code
Fixes #126425
Replace the potentially panicking `[]` indexing with `get_unchecked()` to prevent linking with panic-related code.
|
|
Stabilise `const_char_encode_utf16`.
Closes: #130660
This PR stabilises the `const_char_encode_utf16` feature gate (i.e. support for `char::encode_utf16` in constant expressions).
~~Note that the linked tracking issue is as of this writing currently awaiting FCP until 2024-11-02.~~
|
|
CI in [1] seems to indicate that there are cases where the `f16`
infinite recursion bug ([2], [3]) can make its way into what gets called
during tests, even though this doesn't seem to be the usual case. In
order to make sure that we avoid these completely, just unset
`f16_enabled` on any platforms that have the recursion problem.
This also refactors the `match` statement to be more in line with
`library/std/build.rs`.
[1]: https://github.com/rust-lang/compiler-builtins/pull/729
[2]: https://github.com/llvm/llvm-project/issues/97981
[3]: https://github.com/rust-lang/compiler-builtins/issues/651
|
|
also move internal const_panic helpers to a better location
|
|
docs: fix grammar in doc comment at unix/process.rs
Fixed the grammar of a sentence in the docs
|
|
Improve example of `impl Pattern for &[char]`
The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
|
|
|
|
|
|
|
|
|
|
The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
|
|
|
|
|
|
|
|
Fixes #126425
Replace the potentially panicking `[]` indexing with `get_unchecked()`
to prevent linking with panic-related code.
|
|
add rustc std workspace crate sources
This adds the sources for the crates listed at https://crates.io/search?q=rustc-std-workspace in this repo. The first commit adds the original sources as downloaded from crates.io (with `Cargo.toml.orig` moved back over `Cargo.toml`), and adds a README explaining what this is about. The 2nd commit updates the sources to make the core and alloc crates re-exports of the "actual" core and alloc crates, as was already the case with `std`, and also adds a `repository` link to the manifest so one can figure out where to find these crates.
I bumped the version for the core and alloc crates in the hope that the new versions can be published on crates.io shortly after this PR lands.
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/rustc-std-workspace-core.20crate.20is.20empty) for a bit more context.
r? `@Amanieu`
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #131222 (Generate correct symbols.o for sparc-unknown-none-elf)
- #132423 (remove const-support for align_offset and is_aligned)
- #132565 (Reduce dependence on the target name)
- #132576 (remove attribute ids from hir stats (they're simply not needed))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
- make rustc-std-workspace-core/alloc re-exports of their underlying crates, like std
= cleanup manifests
|
|
remove const-support for align_offset and is_aligned
As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.
Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.
In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.
Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
|
|
Update `compiler-builtins` and enable f128 tests on all non-buggy platforms
Update compiler_builtins to 0.1.138 and pin it. This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms.
With that, we now provide symbols necessary to work with `f128` everywhere. This means that we are no longer restricted to systems that provide `f128` symbols themselves, and can enable tests by default.
There are still a handful of platforms that need to remain disabled because of bugs and some that had to get updated.
Math support is still off by default since those symbols are not yet available.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
try-job: test-various
try-job: i686-gnu-nopt
|
