Based on e3fdafc263a4a705a3bec1a6865a4d011b2ec7c5 with a few
minor changes:
- The name sorting function is changed to follow the [version sort]
from the style guide
- the `cmp` function is redesigned to more obviously make a
partial order, by always return `cmp()` of the same variable as
the `!=` above
[version sort]: https://doc.rust-lang.org/nightly/style-guide/index.html#sorting
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
We are moving toward forbidding `missing_fragment_specifier` either in
edition 2024 or unconditionally. Make a first step toward this by
ensuring crates that rely on the old behavior are reported when used as
dependencies.
Tracking issue: <https://github.com/rust-lang/rust/issues/128143>
Rollup of 9 pull requests
Successful merges:
- #126152 (size_of_val_raw: for length 0 this is safe to call)
- #127252 (Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methods)
- #127374 (Tweak "wrong # of generics" suggestions)
- #127457 (Make tidy fast without compromising case alternation)
- #127480 (Fix build failure on vxworks #127084 )
- #127733 (Replace some `mem::forget`'s with `ManuallyDrop`)
- #128120 (Gate `AsyncFn*` under `async_closure` feature)
- #128131 (Import `c_void` rather than using the full path)
- #128133 (Improve spans on evaluated `cfg_attr`s.)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve spans on evaluated `cfg_attr`s.
When converting something like `#![cfg_attr(cond, attr)]` into `#![attr]`, we currently duplicate the `#` token and the `!` token. But weirdly, there is also this comment:
// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.
Maybe that comment used to be true? But now it is false: we can duplicate the existing delimiters (and their spans and spacing), much like we do for the `#` and `!`.
This commit does that, thus removing the incorrect comment, and improving the spans on `Group`s in a few proc-macro tests.
`@petrochenkov`
Import `c_void` rather than using the full path
Follow up to #128092. As requested, this imports `c_void` in more places. I also fixed up some imports to use `core` for core types instead of `crate`. While that is not strictly necessary, I think ideally things in `sys/pal` should only depend on itself or core so that the code is less spaghetti. We're far away from that ideal at the moment but I can at least try to slowly move in that direction.
Also this forbids `unsafe_op_in_unsafe_fn` for library/std/src/sys/pal/windows by fixing up the remaining unsafe bits that are just punting their unsafe requirements onto the caller of the `unsafe` function (or definition macro).
<!--
r? workingjubilee
-->
Gate `AsyncFn*` under `async_closure` feature
T-lang has not come to a consensus on the naming of async closure callable bounds, and as part of allowing the async closures RFC merge, we agreed to place `AsyncFn` under the same gate as `async Fn` so that these syntaxes can be evaluated in parallel.
See https://github.com/rust-lang/rfcs/pull/3668#issuecomment-2246435537
r? oli-obk
Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
Fix build failure on vxworks #127084
PR to address issue #127084 .
1. Skip `reset_segpipe` for vxworks
2. Return unimplemented error for vxworks from settimes and lchown
3. Temporarily skip dirfd for vxworks
4. Add allow unused unsafe on read_at and write_at functions in unix/fs.rs
5. Using cfg disable ON_BROKEN_PIPE_FLAG_USED and on_broken_pipe_flag_used() for vxworks
6. Remove old crate::syscommon:🧵:min_stack() reference from process_vxworks.rs and update to set stack size of rtpthread
Thank you.
Make tidy fast without compromising case alternation
Fixes tidy speed issue but still catches case-alternation, enabled for other `style.rs` files, and also detects test files better.
r? `@albertlarsan68`
`@Nilstrieb`
Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methods
Some architectures (i386) do not define a "count leading zeros" instruction, they define a "find first set bit" instruction (`bsf`) whose result is undefined when given zero (ie none of the bits are set). Of this family of bitwise operations, I always forget which of these things is potentially undefined for zero, and I'm also not 100% sure that Rust provides a hard guarantee for the results of these methods when given zero. So I figured there are others who have these same uncertainties, and it would be good to resolve them and answer the question via extending these doc examples/tests.
See https://en.wikipedia.org/wiki/Find_first_set#Hardware_support for more info on i386 and `bsf` on zero.
Do not use global caches if opaque types can be defined
fixes#119272
r? `@lcnr`
This is certainly a crude way to make the cache sound wrt opaque types, but since perf lets us get away with this, let's do it in the old solver and let the new solver fix this correctly once and for all.
cc https://github.com/rust-lang/rust/pull/122192#issuecomment-2149252655
When converting something like `#![cfg_attr(cond, attr)]` into
`#![attr]`, we currently duplicate the `#` token and the `!` token. But
weirdly, there is also this comment:
// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.
Maybe that comment used to be true? But now it is false: we can
duplicate the existing delimiters (and their spans and spacing), much
like we do for the `#` and `!`.
This commit does that, thus removing the incorrect comment, and
improving the spans on `Group`s in a few proc-macro tests.
Add `gettid` support
Add support for `gettid` in miri.
To ensure that the requirement that `getpid() == gettdi()` for the main thread, we use the value returned by `getpid` and add to it the internal thread index.
Since `getpid` is only supported when isolation is disabled, and we want `gettid` to be used both in isolated and non-isolated executions, we modify `getpid` to return a hardcoded value (1000) when running in isolation mode.
Fixes#3730
In order to support gettid when isolation is enabled and when it is
disabled, and satisfy its requirement that:
In a single-threaded process, the thread ID is equal to the process ID
(PID, as returned by getpid(2)).
we define the thread ID to be getpid() + <miri internal thread id>.
Since the internal thread id of the main thread is zero, this will
satisfy that requirement.
However, getpid for now was only supported when isolation was disabled.
To support getpid in isolation mode, we return a hardcoded value (1000)
and return that instead of the real PID.
Use ControlFlow in more places
Now, instead of manually using variables in visitors to signify that a visit is "done" and that the visitor should stop traversing. We use the trait type "Result" to signify this (in relevant places).
I'll schedule a perf run, I don't think it will be much of a difference, but every bit of performance is welcomed :)
changelog: Improve performance, less memory use in visitors
Fixes#12829
r? `@y21`
Make ast `MutVisitor` have the same method name and style as `Visitor`
It doesn't map 100% because some `MutVisitor` methods can filter or even expand to multiple items, but consistency seems nicer.
tracking issue: https://github.com/rust-lang/rust/issues/127615
Make ast `MutVisitor` have the same method name and style as `Visitor`
It doesn't map 100% because some `MutVisitor` methods can filter or even expand to multiple items, but consistency seems nicer.
tracking issue: https://github.com/rust-lang/rust/issues/127615
Rollup of 8 pull requests
Successful merges:
- #125962 (Update tracking issue for `const_binary_heap_new_in`)
- #126770 (Add elem_offset and related methods)
- #127481 (Remove generic lifetime parameter of trait `Pattern`)
- #128043 (Docs for core::primitive: mention that "core" can be shadowed, too, so we should write "::core")
- #128092 (Remove wrapper functions from c.rs)
- #128100 (Allow to pass a full path for `run-make` tests)
- #128106 (Fix return type of FileAttr methods on AIX target)
- #128108 (ensure std step before preparing sysroot)
r? `@ghost`
`@rustbot` modify labels: rollup
ensure std step before preparing sysroot
When using download-rustc, any stage other than 0 or 1 (e.g., cargo +stage2 build/doc) will fail to find std while compiling on simple rust sources. Ensuring the std step fixes this issue.
r? Kobzol
Fix return type of FileAttr methods on AIX target
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
Allow to pass a full path for `run-make` tests
It's common (at least for me) to pass a full path to a `run-make` test (including the `rmake.rs` file) and to see that it isn't found, which is a bit frustrating.
With these changes, we can now optionally pass the `rmake.rs` (or even `Makefile`) at the end of the path.
cc ```@jieyouxu```
r? ```@Kobzol```
Remove wrapper functions from c.rs
I'd like for the windows `c.rs` just to contain the basic platform definitions and not anything higher level unless absolutely necessary. So this removes some wrapper functions that weren't really necessary in any case. The functions are only used in a few places which themselves are relatively thin wrappers. The "interesting" bit is that we had an `AlertableIoFn` that abstracted over `ReadFileEx` and `WriteFileEx`. I've replaced this with a closure.
Also I removed an `#[allow(unsafe_op_in_unsafe_fn)]` while I was moving things around.
