| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Remove polymorphization
This PR removes the flag `-Zpolymorphize` and all the infrastructure in the compiler that exists only to support it, per https://github.com/rust-lang/compiler-team/issues/810.
|
|
Implementation of `fmt::FormattingOptions`
Tracking issue: #118117
Public API:
```rust
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub struct FormattingOptions { … }
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum Sign {
Plus,
Minus
}
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum DebugAsHex {
Lower,
Upper
}
impl FormattingOptions {
pub fn new() -> Self;
pub fn sign(&mut self, sign: Option<Sign>) -> &mut Self;
pub fn sign_aware_zero_pad(&mut self, sign_aware_zero_pad: bool) -> &mut Self;
pub fn alternate(&mut self, alternate: bool) -> &mut Self;
pub fn fill(&mut self, fill: char) -> &mut Self;
pub fn align(&mut self, alignment: Option<Alignment>) -> &mut Self;
pub fn width(&mut self, width: Option<usize>) -> &mut Self;
pub fn precision(&mut self, precision: Option<usize>) -> &mut Self;
pub fn debug_as_hex(&mut self, debug_as_hex: Option<DebugAsHex>) -> &mut Self;
pub fn get_sign(&self) -> Option<Sign>;
pub fn get_sign_aware_zero_pad(&self) -> bool;
pub fn get_alternate(&self) -> bool;
pub fn get_fill(&self) -> char;
pub fn get_align(&self) -> Option<Alignment>;
pub fn get_width(&self) -> Option<usize>;
pub fn get_precision(&self) -> Option<usize>;
pub fn get_debug_as_hex(&self) -> Option<DebugAsHex>;
pub fn create_formatter<'a>(self, write: &'a mut (dyn Write + 'a)) -> Formatter<'a>;
}
impl<'a> Formatter<'a> {
pub fn new(write: &'a mut (dyn Write + 'a), options: FormattingOptions) -> Self;
pub fn with_options<'b>(&'b mut self, options: FormattingOptions) -> Formatter<'b>;
pub fn sign(&self) -> Option<Sign>;
pub fn options(&self) -> FormattingOptions;
}
```
Relevant changes from the public API in the tracking issue (I'm leaving out some stuff I consider obvious mistakes, like missing `#[derive(..)]`s and `pub` specifiers):
- `enum DebugAsHex`/`FormattingOptions::debug_as_hex`/`FormattingOptions::get_debug_as_hex`: To support `{:x?}` as well as `{:X?}`. I had completely missed these options in the ACP. I'm open for any and all bikeshedding, not married to the name.
- `fill`/`get_fill` now takes/returns `char` instead of `Option<char>`. This simply mirrors what `Formatter::fill` returns (with default being `' '`).
- Changed `zero_pad`/`get_zero_pad` to `sign_aware_zero_pad`/`get_sign_aware_zero_pad`. This also mirrors `Formatter::sign_aware_zero_pad`. While I'm not a fan of this quite verbose name, I do believe that having the interface of `Formatter` and `FormattingOptions` be compatible is more important.
- For the same reason, renamed `alignment`/`get_alignment` to `aling`/`get_align`.
- Deviating from my initial idea, `Formatter::with_options` returns a `Formatter` which has the lifetime of the `self` reference as its generic lifetime parameter (in the original API spec, the generic lifetime of the returned `Formatter` was the generic lifetime used by `self` instead). Otherwise, one could construct two `Formatter`s that both mutably borrow the same underlying buffer, which would be unsound. This solution still has performance benefits over simply using `Formatter::new`, so I believe it is worthwhile to keep this method.
|
|
|
|
fix SC fence logic
|
|
|
|
|
|
Stabilize noop_waker
Tracking Issue: #98286
This is a handy feature that's been used widely in tests and example async code and it'd be nice to make it available to users.
cc `@rust-lang/wg-async`
|
|
Sync cg clif 2024 12 06
The main highlights this time are a Cranelift update disabling the clif ir verifier by default for better performance.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
Cranelift being disabled
|
|
sync_cg_clif-2024-12-06
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #130777 (rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973))
- #133211 (Extend Miri to correctly pass mutable pointers through FFI)
- #133790 (Improve documentation for Vec::extend_from_within)
- #133930 (rustbook: update to use new mdbook-trpl package from The Book)
- #133931 (Only allow PassMode::Direct for aggregates on wasm when using the C ABI)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=nnethercote
Only allow PassMode::Direct for aggregates on wasm when using the C ABI
For the Rust ABI we don't have any ABI compat reasons to allow PassMode::Direct for aggregates.
|
|
rustbook: update to use new mdbook-trpl package from The Book
Updates to the latest merge from `rust-lang/book` and simplifies the dependency chain there. There are now three preprocessors, but only one package, so everything is a lot nicer to deal with from the consuming POV (i.e. here).
|
|
Improve documentation for Vec::extend_from_within
This closes #104762.
It rephrases some of the explanations, and greatly improves the clarity of the example.
Based on this PR and its discussions:
https://github.com/rust-lang/rust/pull/105030/files#r1059808792
|
|
Extend Miri to correctly pass mutable pointers through FFI
Based off of https://github.com/rust-lang/rust/pull/129684, this PR further extends Miri to execute native calls that make use of pointers to *mutable* memory.
We adapt Miri's bookkeeping of internal state upon any FFI call that gives external code permission to mutate memory.
Native code may now possibly write and therefore initialize and change the pointer provenance of bytes it has access to: Such memory is assumed to be *initialized* afterwards and bytes are given *arbitrary (wildcard) provenance*. This enables programs that correctly use mutating FFI calls to run Miri without errors, at the cost of possibly missing Undefined Behaviour caused by incorrect usage of mutating FFI.
> <details>
>
> <summary> Simple example </summary>
>
> ```rust
> extern "C" {
> fn init_int(ptr: *mut i32);
> }
>
> fn main() {
> let mut x = std::mem::MaybeUninit::<i32>::uninit();
> let x = unsafe {
> init_int(x.as_mut_ptr());
> x.assume_init()
> };
>
> println!("C initialized my memory to: {x}");
> }
> ```
> ```c
> void init_int(int *ptr) {
> *ptr = 42;
> }
> ```
> should now show `C initialized my memory to: 42`.
>
> </details>
r? ``@RalfJung``
|
|
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)
Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.
- Tracking issue: https://github.com/rust-lang/rust/issues/116973
|
|
For the Rust ABI we don't have any ABI compat reasons to allow
PassMode::Direct for aggregates.
|
|
Fix weak memory emulation to avoid generating behaviors that are forbidden under C++ 20
|
|
Automatic Rustup
|
|
|
|
|
|
compiler-errors:structurally-resolve-adjust-for-branch, r=lcnr
Structurally resolve in `adjust_for_branches`
r? lcnr
|
|
If a type has unsafe fields, its safety invariants are not simply
the conjunction of its field types' safety invariants. Consequently,
it's invalid to reason about the safety properties of these types
in a purely structural manner — i.e., the manner in which `auto`
traits are implemented.
Makes progress towards #132922.
|
|
Rollup of 8 pull requests
Successful merges:
- #132155 (Always display first line of impl blocks even when collapsed)
- #133256 (CI: use free runners for i686-gnu jobs)
- #133607 (implement checks for tail calls)
- #133821 (Replace black with ruff in `tidy`)
- #133827 (CI: rfl: move job forward to Linux v6.13-rc1)
- #133910 (Normalize target-cpus.rs stdout test for LLVM changes)
- #133921 (Adapt codegen tests for NUW inference)
- #133936 (Avoid fetching the anon const hir node that is already available)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Avoid fetching the anon const hir node that is already available
|
|
Adapt codegen tests for NUW inference
These were broken by https://github.com/llvm/llvm-project/commit/462cb3cd6cecd0511ecaf0e3ebcaba455ece587d
Let me know if you think we should have a FIXME / tracking issue to update the tests after the LLVM 20 upgrade to make these required.
`@rustbot` label: +llvm-main
r? `@nikic`
|
|
Normalize target-cpus.rs stdout test for LLVM changes
LLVM has recently added support for the `lime1` CPU in https://github.com/llvm/llvm-project/commit/35cce408eef1a253df12c0023c993d78b180b1f3, so the `target-cpus.rs` test currently produces different output depending on the LLVM version.
This CL adds a normalization directive, to remove the new CPU from the output list.
Alternatives fixes I can think of:
* Add two revisions of the test (one per LLVM version)
* Ignore the test on one of the LLVM versions
* I dislike this, because it's possible that the test won't get updated for the next LLVM version.
I don't think the exact list of target CPUs is relevant for this test, so it shouldn't be too bad if the normalization sticks around longer than necessary.
`@rustbot` label: +llvm-main
|
|
CI: rfl: move job forward to Linux v6.13-rc1
Linux v6.13-rc1 contains commit 28e848386b92 ("rust: block: fix formatting of `kernel::block::mq::request` module"), which in turn contains commit c95bbb59a9b2 ("rust: enable arbitrary_self_types and remove `Receiver`"), which is why we had a hash rather than a tag.
r? ```@Kobzol``` ```@lqd```
try-job: x86_64-rust-for-linux
```@rustbot``` label A-rust-for-linux
```@bors``` try
|
|
Replace black with ruff in `tidy`
`ruff` can both lint and format Python code (in fact, it should be a mostly drop-in replacement for `black` in terms of formatting), so it's not needed to use `black` anymore. This PR removes `black` and replaces it with `ruff`, to get rid of one Python dependency, and also to make Python formatting faster (although that's a small thing).
If we decide to merge this, we'll need to "reformat the world" - `ruff` is not perfectly compatible with `black`, and it also looks like `black` was actually ignoring some files before. I tried it locally (`./x test tidy --extra-checks=py:fmt --bless`) and it also reformatted some code in subtrees (e.g. `clippy` or `rustc_codegen_gcc`) - I'm not sure how to handle that.
|
|
implement checks for tail calls
Quoting the [RFC draft](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md):
> The argument to become is a function (or method) call, that exactly matches the function signature and calling convention of the callee. The intent is to ensure a matching ABI. Note that lifetimes may differ as long as they pass borrow checking, see [below](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md#return-type-coercion) for specifics on the return type.
> Tail calling closures and tail calling from closures is not allowed. This is due to the high implementation effort, see below, this restriction can be lifted by a future RFC.
> Invocations of operators were considered as valid targets but were rejected on grounds of being too error-prone. In any case, these can still be called as methods.
> Tail calling [variadic functions](https://doc.rust-lang.org/beta/unstable-book/language-features/c-variadic.html) and tail calling from variadic functions is not allowed. As support for variadic function is stabilized on a per target level, support for tail-calls regarding variadic functions would need to follow a similar approach. To avoid this complexity and to minimize implementation effort for backends, this interaction is currently not allowed but support can be added with a future RFC.
-----
The checks are implemented as a query, similarly to `check_unsafety`.
The code is cherry-picked straight out of #112657 which was written more than a year ago, so I expect we might need to change some things ^^"
|
|
CI: use free runners for i686-gnu jobs
try-job: i686-gnu-1
try-job: i686-gnu-2
try-job: i686-gnu-nopt-1
try-job: i686-gnu-nopt-2
|
|
Always display first line of impl blocks even when collapsed
Fixes https://github.com/rust-lang/rust/issues/130612.
It the line is too long, only the beginning will be visible:
Otherwise, it looks like this:
Can be tested [here](https://rustdoc.crud.net/imperio/impl-block-doc/foo/struct.ImplDoc.html).
r? `@notriddle`
|
|
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
See https://github.com/rust-lang/rust/pull/118159#discussion_r1495760867
for context.
|
|
|
|
|
