Xous has a concept of `services` that provide various features.
Processes may connect to these services by name or by address. Most
services require a name server in order to connect.
Add a file with the most common services, and provide a way to connect
to a service by querying the name server.
Signed-off-by: Sean Cross <sean@xobs.io>
Basic alloc support on Xous is supported by the `dlmalloc` crate. This
necessitates bumping the dlmalloc version to 0.2.4.
Signed-off-by: Sean Cross <sean@xobs.io>
Add the basics to get the operating system running, including how to
exit the operating system.
Since Xous has no libc, there is no default entrypoint. Add a `_start`
entrypoint to the system-specific os module.
Signed-off-by: Sean Cross <sean@xobs.io>
Xous has no C FFI. Instead, all FFI is done via syscalls that are
specified in Rust. Add these FFI calls to libstd, as well as some of the
currently-supported syscalls.
This enables Rust programs to interact with the Xous operating system
while avoiding adding an extra dependency to libstd.
Signed-off-by: Sean Cross <sean@xobs.io>
custom_mir: change Call() terminator syntax to something more readable
I find our current syntax very hard to read -- I cannot even remember the order of arguments, and having the "next block" *before* the actual function call is very counter-intuitive IMO. So I suggest we use `Call(ret_val = function(v), next_block)` instead.
r? `@JakobDegen`
Fix UB in `std::sys::os::getenv()`
Fixes#114949.
Reduced the loops to 1k iterations (100k was taking way too long), Miri no longer shows any UB.
`@rustbot` label +A-process +C-bug +I-unsound +O-unix
rustdoc: Add lint `redundant_explicit_links`
Closes#87799.
- Lint warns by default
- Reworks link parser to cache original link's display text
r? `@jyn514`
Usage zero as language id for `FormatMessageW()`
This switches the language selection from using system language (note that this might be different than application language, typically stored as thread ui language) to use `FormatMessageW` default search strategy, which is `neutral` first, then `thread ui lang`, then `user language`, then `system language`, then `English`. (See https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessagew)
This allows the Rust program to take more control of `std::io::Error`'s message field, by setting up thread ui language themselves before hand (which many programs already do).
Inline strlen_rt in CStr::from_ptr
This enables LLVM to optimize this function as if it was strlen (LLVM knows what it does, and can avoid calling it in certain situations) without having to enable std-aware LTO. This is essentially doing what https://github.com/rust-lang/rust/pull/90007 did, except updated for this function being `const`.
Pretty sure it's safe to roll-up, considering last time I did make this change it didn't affect performance (`CStr::from_ptr` isn't really used all that often in Rust code that is checked by rust-perf).
Increase clarity about Hash - Eq consistency in HashMap and HashSet docs
As discussed [here](https://users.rust-lang.org/t/what-hapens-if-hash-and-partialeq-dont-match-when-using-hashmap/98052/13) the description of logic errors in `HashMap` and `HashSet` does not explicitly apply to
```text
k1 == k2 -> hash(k1) == hash(k2)
```
but this is likely what is intended.
This PR is a small doc change to correct this.
r? rust-lang/libs
Add `modulo` and `mod` as doc aliases for `rem_euclid`.
When I was learning Rust I looked for “a modulo function” and couldn’t find one, so thought I had to write my own; it wasn't at all obvious that a function with “rem” in the name was the function I wanted. Hopefully this will save the next learner from that.
However, it does have the disadvantage that the top results in rustdoc for “mod” are now these aliases instead of the Rust keyword, which probably isn't ideal.
Add doc aliases for trigonometry and other f32,f64 methods.
These are common alternate names, usually a less-abbreviated form, for the operation; e.g. `arctan` instead of `atan`. Prompted by <https://users.rust-lang.org/t/64-bit-trigonometry/98599>
When I was learning Rust I looked for “a modulo function” and couldn’t
find one, so thought I had to write my own; it wasn't at all obvious
that a function with “rem” in the name was the function I wanted.
Hopefully this will save the next learner from that.
However, it does have the disadvantage that the top results in rustdoc
for “mod” are now these aliases instead of the Rust keyword, which
probably isn't ideal.
Synchronize with all calls to `unpark` in id-based thread parker
[The documentation for `thread::park`](https://doc.rust-lang.org/nightly/std/thread/fn.park.html#memory-ordering) guarantees that "park synchronizes-with all prior unpark operations". In the id-based thread parking implementation, this is not implemented correctly, as the state variable is reset with a simple store, so there will not be a *synchronizes-with* edge if an `unpark` happens just before the reset. This PR corrects this, replacing the load-check-reset sequence with a single `compare_exchange`.
Partially revert #107200
`Ok(0)` is indeed something the caller may interpret as an error, but
that's the *correct* thing to return if the writer can't accept any more
bytes.
avoid transmuting Box when we can just cast raw pointers instead
Always better to avoid a transmute, in particular when the layout assumptions it is making are not clearly documented. :)
Rollup of 5 pull requests
Successful merges:
- #113115 (we are migrating to askama)
- #114784 (Improve `invalid_reference_casting` lint)
- #114822 (Improve code readability by moving fmt args directly into the string)
- #114878 (rustc book: make more pleasant to search)
- #114899 (Add missing Clone/Debug impls to SMIR Trait related tys)
r? `@ghost`
`@rustbot` modify labels: rollup
Optimizing the rest of bool's Ord implementation
After coming across issue #66780, I realized that the other functions provided by Ord (`min`, `max`, and `clamp`) were similarly inefficient for bool. This change provides implementations for them in terms of boolean operators, resulting in much simpler assembly and faster code.
Fixes issue #114653
[Comparison on Godbolt](https://rust.godbolt.org/z/5nb5P8e8j)
`max` assembly before:
```assembly
example::max:
mov eax, edi
mov ecx, eax
neg cl
mov edx, esi
not dl
cmp dl, cl
cmove eax, esi
ret
```
`max` assembly after:
```assembly
example::max:
mov eax, edi
or eax, esi
ret
```
`clamp` assembly before:
```assembly
example:🗜️
mov eax, esi
sub al, dl
inc al
cmp al, 2
jae .LBB1_1
mov eax, edi
sub al, sil
movzx ecx, dil
sub dil, dl
cmp dil, 1
movzx edx, dl
cmovne edx, ecx
cmp al, -1
movzx eax, sil
cmovne eax, edx
ret
.LBB1_1:
; identical assert! code
```
`clamp` assembly after:
```assembly
example:🗜️
test edx, edx
jne .LBB1_2
test sil, sil
jne .LBB1_3
.LBB1_2:
or dil, sil
and dil, dl
mov eax, edi
ret
.LBB1_3:
; identical assert! code
```
Cleaner assert_eq! & assert_ne! panic messages
This PR finishes refactoring of the assert messages per #94005. The panic message format change #112849 used to be part of this PR, but has been factored out and just merged. It might be better to keep both changes in the same release once FCP vote completes.
Modify panic message for `assert_eq!`, `assert_ne!`, the currently unstable `assert_matches!`, as well as the corresponding `debug_assert_*` macros.
```rust
assert_eq!(1 + 1, 3);
assert_eq!(1 + 1, 3, "my custom message value={}!", 42);
```
#### Old messages
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion failed: `(left == right)`
left: `2`,
right: `3`
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion failed: `(left == right)`
left: `2`,
right: `3`: my custom message value=42!
```
#### New messages
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion `left == right` failed
left: 2
right: 3
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion `left == right` failed: my custom message value=42!
left: 2
right: 3
```
History of fixing #94005
* #94016 was a lengthy PR that was abandoned
* #111030 was similar, but it stringified left and right arguments, and thus caused compile time performance issues, thus closed
* #112849 factored out the two-line formatting of all panic messages
Fixes#94005
r? `@m-ou-se`
