coverage: Don't underflow column number
I noticed this when running coverage on a debug build of rustc. There
may be other places that do this but I'm just fixing the one I hit.
r? `@wesleywiser` `@richkadel`
Add regression tests for const-generic inherent associated types
Fixes#109759.
The tests are no longer failing since #96840 which was merged recently (#109410 is no longer necessary for them).
`@rustbot` label F-inherent_associated_types
Use the standard macOS CI runner
This moves back to the standard macOS CI runner instead of the large runners. The infra team is discussing whether the large runners are worth the cost at our heavy usage and whether those credits are better spent elsewhere. This will slow down CI build times unfortunately, but while we figure out our CI spending budget, that's a price we'll unfortunately have to pay.
r? `@pietroalbini`
Fix `std` compilation error for wasi+atomics
Fix https://github.com/rust-lang/rust/issues/109727
It seems that the `unsupported/once.rs` module isn't meant to exist at the same time as the `futex` module, as they have conflicting definitions.
I've solved this by defining the `once` module only if `not(target_feature = "atomics")`.
The `wasm32-unknown-unknown` target [similarly only defines the `once` module if `not(target_feature = "atomics")`](01c4f31927/library/std/src/sys/wasm/mod.rs (L69-L70)).
As show in [this block of code](01c4f31927/library/std/src/sys_common/once/mod.rs (L10-L34)), the `sys::once` module doesn't need to exist if `all(target_arch = "wasm32", target_feature = "atomics")`.
Improve tests for #110138
These should live in rustdoc-json, not rustdoc-ui, so we can run assertions, and not just check there's no ICE
CC #100515, as we never document this suite
r? rustdoc
Update documentation wording on path 'try_exists' functions
Just eliminate the quadruple negation in `doesn't silently ignore errors unrelated to ... not existing.`
Replace `yes` command by `while-echo` in test `tests/ui/process/process-sigpipe.rs`
The `yes` command is not available on all platforms.
Fixes#108596.
Inviting `@mvf` as he contributed to this patch. Thanks! This issue has been discussed in https://github.com/rust-lang/rust/pull/106673 but was moved to #108596 to get going.
CC `@gh-tr`
r? `@workingjubilee`
`@rustbot` label +O-neutrino
Notes about the comments https://github.com/rust-lang/rust/pull/106673#discussion_r1117324265:
- The `echo` command is `/proc/boot/echo` (not built-in)
- `/bin/sh` is a symlink to `/proc/boot/ksh`
```sh
# ls -l /bin/sh /proc/boot/ksh /proc/boot/echo
lrwxrwxrwx 1 root root 14 Mar 20 07:52 /bin/sh -> /proc/boot/ksh
-r-xr-xr-x 1 root root 9390 Sep 12 2022 /proc/boot/echo
-r-xr-xr-x 1 root root 308114 Sep 12 2022 /proc/boot/ksh
```
black_box doc corrections for clarification - Issue #107957
Made a complete pass through the docs to help resolve https://github.com/rust-lang/rust/issues/107957
No code changes, just documentation
`@rustbot` label +T-libs-api -T-libs
Rewrite MemDecoder around pointers not a slice
This is basically https://github.com/rust-lang/rust/pull/109910 but I'm being a lot more aggressive. The pointer-based structure means that it makes a lot more sense to absorb more complexity into `MemDecoder`, most of the diff is just complexity moving from one place to another.
The primary argument for this structure is that we only incur a single bounds check when doing multi-byte reads from a `MemDecoder`. With the slice-based implementation we need to do those with `data[position..position + len]` , which needs to account for `position + len` wrapping. It would be possible to dodge the first bounds check if we stored a slice that starts at `position`, but that would require updating the pointer and length on every read.
This PR also embeds the failure path in a separate function, which means that this PR should subsume all the perf wins observed in https://github.com/rust-lang/rust/pull/109867.
Use `?0` notation for ty/ct/int/float/region vars
Aligns the notation for infer vars that T-types and friends most often uses for inference variables with the notation in the compiler (which is kinda a sigil nightmare IMO: `_#`) by adopting `?0` style infer vars.
This mostly affects debug output since verbose infer vars shouldn't show up in user-facing places.
Does this need an MCP? It's debug output, so I'm thinking no, but happy to open one. 🤔
r? types
Rollup of 6 pull requests
Successful merges:
- #110556 (Switch to `EarlyBinder` for `explicit_item_bounds`)
- #110615 (Add `impl_tag!` macro to implement `Tag` for tagged pointer easily)
- #110649 (Fix no_global_oom_handling build)
- #110671 (Consider polarity in new solver)
- #110783 (Fix ICE on --print=... i/o errors)
- #110796 (Updating Wake example to use new 'pin!' macro)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Updating Wake example to use new 'pin!' macro
Closes: https://github.com/rust-lang/rust/issues/109965
I have already had this reviewed and approved here: https://github.com/rust-lang/rust/pull/110026 . But because I had some git issues and chose the "nuke it" option as my solution it didn't get merged. I nuked it too quickly. I am sorry for trouble of reviewing twice.
Consider polarity in new solver
It's kinda ugly to have a polarity check in all of the builtin impls -- I guess I could consider the polarity at the top of assemble-builtin but that would require adding a polarity fn to `GoalKind`...
🤷 putting this up just so i dont forget, since it's needed to bootstrap core during coherence (this alone does not allow core to bootstrap though, additional work is needed!)
r? ``@lcnr``
Fix no_global_oom_handling build
`provide_sorted_batch` in core is incorrectly marked with `#[cfg(not(no_global_oom_handling))]` which prevents core from building with the cfg enabled.
Nothing in `core` allocates memory (including this function). The `cfg` gate is incorrect.
cc ``@dpaoliello``
r? ``@wesleywiser``
The cfg was added by #107191
Add `impl_tag!` macro to implement `Tag` for tagged pointer easily
r? `@Nilstrieb`
This should also lifts the need to think about safety from the callers (`impl_tag!` is robust (ish, see the macro issue)) and removes the possibility of making a "weird" `Tag` impl.
Switch to `EarlyBinder` for `explicit_item_bounds`
Part of the work to finish https://github.com/rust-lang/rust/issues/105779.
This PR adds `EarlyBinder` to the return type of the `explicit_item_bounds` query and removes `bound_explicit_item_bounds`.
r? `@compiler-errors` (hope it's okay to request you, since you reviewed #110299 and #110498😃)
Add shortcut for Grisu3 algorithm.
While Grisu3 is way more faster for most numbers compare to Dragon4, the fall back to Dragon4 procedure for certain numbers could cause some performance regressions compare to use Dragon4 directly. Mitigating the regression caused by falling back is important for a largely used core library.
In Grisu3 algorithm implementation, there's a shortcut to jump out earlier when the fractional or integrals cannot meet the requirement of requested digits. This could significantly improve the performance of converting floating number to string as it falls back even without starting trying the algorithm.
The original idea is from the [.NET implementation](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Number.Grisu3.cs#L602-L615) and the code was originally added in [this PR](https://github.com/dotnet/coreclr/pull/14646#issuecomment-350942050). This shortcut has been shipped long time ago and has been proved working.
Fix#110129
configure.py: add flag for riscv{64,32}gc musl-root
Add the corresponding flag for detecting `--musl-root-riscv64gc` and `--musl-root-riscv32gc` with ./configure, which is beneficial for downstream Linux distros to create the rust package with the same "recipe" from other architectures.
Update books
## rust-lang/book
1 commits in c06006157b14b3d47b5c716fc392b77f3b2e21ce..8fa6b854d515506d825390fe0d817f5ef0c89350
2023-04-13 00:05:30 UTC to 2023-04-13 00:05:30 UTC
- Update copyright in LICENSE-APACHE (rust-lang/book#3611)
## rust-embedded/book
1 commits in 701d1551429da4cb609082c0ac99df569e336710..897fcf566f16bf87bf37199bdddec1801fd00532
2023-04-20 13:24:51 UTC to 2023-04-20 13:24:51 UTC
- typos (rust-embedded/book#347)
## rust-lang/rustc-dev-guide
5 commits in 6337ed17fb8dcd918d78b7d97d213e923530337c..2a5eb92197e9cf8fe91164dcbf4f9b88c0d7e73d
2023-04-22 11:50:11 UTC to 2023-04-16 11:30:24 UTC
- Add docs for compare-output-lines-by-subset flag (rust-lang/rustc-dev-guide#1677)
- fix typo (rust-lang/rustc-dev-guide#1674)
- Fix links in how-to-build-and-run.md (rust-lang/rustc-dev-guide#1679)
- docs: document new `suggest-tests` tool (rust-lang/rustc-dev-guide#1660)
- Fix extra slash (rust-lang/rustc-dev-guide#1673)
[LLVM17] Adapt to `ExplicitEmulatedTLS` removal.
0d333bf0e3 removed the `ExplicitEmulatedTLS` field from `TargetOptions`.
Before that commit, `TargetMachine::useEmulatedTLS()` fell back to `TheTriple.hasDefaultEmulatedTLS()` if `ExplicitEmulatedTLS` was `false`/unset.
After that commit, `TargetMachine::useEmulatedTLS()` directly returns `Options.EmulatedTLS`, and the fallback to `TheTriple.hasDefaultEmulatedTLS()` was moved to `InitTargetOptionsFromCodeGenFlags`.
Since `rustc` does not use `InitTargetOptionsFromCodeGenFlags` (AFAICT) and instead manually builds `TargetOptions`, this PR initializes `EmulatedTLS` to `TheTriple.hasDefaultEmulatedTLS()`.
(I'm not really familiar with the details of what this option does, or if there are any tests that depend on `hasDefaultEmulatedTLS` being used correctly, so this PR is mostly untested (it does compile against LLVM17, though)).
`@rustbot` label: +llvm-main
Break up long function in trait selection error reporting + clean up nearby code
- Move blocks of code into their own functions
- Replace a few function argument types with their type aliases
- Create "AppendConstMessage" enum to replace a nested `Option`.
Check requested digit length and the fractional or integral parts of the number. Falls back earlier without trying the Grisu algorithm if the specific condition meets.
Fix#110129
Allow older LLVM versions to have missing components
This check was introduced by #77280 to ensure that all tests that are filtered by LLVM component are actually tested in CI. However this causes issues for new targets (e.g. #101069) where support is only available on the latest LLVM version.
This PR restricts the tests to only CI jobs that use the latest LLVM version.
