Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 11 pull requests #120237

Closed
wants to merge 29 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

fmease and others added 29 commits December 20, 2023 18:16
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations).

Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).
By "actual" we refer to the uplifting logic where we may not compile the requested stage;
instead, we uplift it from the previous stages. Which can lead to bootstrap failures in
specific situations where we request stage X from other steps. However we may end up
uplifting it from stage Y, causing the other stage to fail when attempting to link with
stage X which was never actually built.

Signed-off-by: onur-ozkan <[email protected]>
Before making thread_local accept statements inside the const block,
this test would fail to compile as follows:

    error: no rules expected the token `let`
       --> library/std/tests/thread.rs:26:13
        |
    26  |             let value = 1;
        |             ^^^ no rules expected this token in macro call
        |
    note: while trying to match meta-variable `$init:expr`
       --> library/std/src/thread/local.rs:189:69
        |
    189 |     ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
        |                                                                     ^^^^^^^^^^
…omcc

Refactor uses of `objc_msgSend` to no longer have clashing definitions

This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations).

Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).

Motivation is to avoid issues with clashing definitions, like described in rust-lang#12707 (comment) and rust-lang#46188 (comment), CC `@bjorn3.`
…tc-crates, r=WaffleLapkin

Undeprecate lint `unstable_features` and make use of it in the compiler

See also rust-lang#117937.

r? compiler
…n,Nilstrieb

Fix deallocation with wrong allocator in (A)Rc::from_box_in

Deallocate the `Box` with the original allocator (via `&A`), not `Global`.

Fixes rust-lang#119749

<details> <summary>Example code with error and Miri output</summary>

(Note that this UB is not observable on stable, because the only usable allocator on stable is `Global` anyway.)

Code ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=96193c2c6a1912d7f669fbbe39174b09)):

```rs
#![feature(allocator_api)]
use std::alloc::System;

// uncomment one of these
use std::rc::Rc;
//use std::sync::Arc as Rc;

fn main() {
    let x: Box<[u32], System> = Box::new_in([1,2,3], System);
    let _: Rc<[u32], System> = Rc::from(x);
}
```

Miri output:

```rs
error: Undefined Behavior: deallocating alloc904, which is C heap memory, using Rust heap deallocation operation
   --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14
    |
117 |     unsafe { __rust_dealloc(ptr, layout.size(), layout.align()) }
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ deallocating alloc904, which is C heap memory, using Rust heap deallocation operation
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: BACKTRACE:
    = note: inside `std::alloc::dealloc` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14: 117:64
    = note: inside `<std::alloc::Global as std::alloc::Allocator>::deallocate` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:254:22: 254:51
    = note: inside `<std::boxed::Box<std::mem::ManuallyDrop<[u32]>> as std::ops::Drop>::drop` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1244:17: 1244:66
    = note: inside `std::ptr::drop_in_place::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>> - shim(Some(std::boxed::Box<std::mem::ManuallyDrop<[u32]>>))` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:507:1: 507:56
    = note: inside `std::mem::drop::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>>` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:992:24: 992:25
    = note: inside `std::rc::Rc::<[u32], std::alloc::System>::from_box_in` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:1928:13: 1928:22
    = note: inside `<std::rc::Rc<[u32], std::alloc::System> as std::convert::From<std::boxed::Box<[u32], std::alloc::System>>>::from` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:2504:9: 2504:27
note: inside `main`
   --> src/main.rs:10:32
    |
10  |     let _: Rc<[u32], System> = Rc::from(x);
    |                                ^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error
```

</details>
…rk-Simulacrum

bootstrap: improvements for compiler builds

Reverted rust-lang#108288 and applied a proper fix with the following commit.

r? ``@Mark-Simulacrum``
…=compiler-errors

Make generic const type mismatches not hide trait impls from the trait solver

pulled out of rust-lang#119895

It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order.

The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.
…ubpats, r=compiler-errors

Report unreachable subpatterns consistently

We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant.

r? ``@compiler-errors``
…s, r=nnethercote

Validate AggregateKind types in MIR

Would have helped me catch some bugs when writing shims for async closures
…-errors

`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`

rust-lang#119752 leveraged and overloaded `is_object_safe` to prevent an ICE, but accurate object safety information is needed for precise suggestions. This separates out `is_downgradable`, used for the ICE prevention, and `is_object_safe`, which returns to its original meaning.
Allow any `const` expression blocks in `thread_local!`

This PR contains a rebase of the macro change from rust-lang#116392, together with adding a test under library/std/tests.

Testing this feature by making the documentation's example code needlessly more complicated was not appropriate as pointed out in rust-lang#116392 (review).

Without the macro change, this new test would fail to build as follows:

```console
error: no rules expected the token `let`
   --> library/std/tests/thread.rs:26:13
    |
26  |             let value = 1;
    |             ^^^ no rules expected this token in macro call
    |
note: while trying to match meta-variable `$init:expr`
   --> library/std/src/thread/local.rs:189:69
    |
189 |     ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
    |                                                                     ^^^^^^^^^^
```

Closes rust-lang#116392.
…_for_builtin, r=petrochenkov

Builtin macros effectively have implicit #[collapse_debuginfo(yes)]

If collapse_debuginfo attribute for builtin macro is not specified explicitly, it will be effectively set to `#[collapse_debuginfo(yes)]`.
…=calebcartwright,ytmimi

rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg

r? `@ytmimi` and/or `@calebcartwright`
cc `@fmease`

I'm putting this on r-l/rust since it should fix the nightly rustfmt version. If you don't care about having this regression until the next rustfmt->rust sync, then I can move that PR over to r-l/rustfmt.

---

> Any idea why the formatting would have changed [from rust-lang#119099]?

**Copied over explanation:**

This has to do with the weirdness of the way that `parse_macro_arg` works. Unlike parsing nonterminal args in a macro-by-example, it eagerly tries, for example, to parse a type without checking that the beginning token may begin a type:

https://github.com/rust-lang/rustfmt/blob/bf967319e258acb9b1648a952bba52665eceaf52/src/parse/macros/mod.rs#L54

Contrast this to the nonterminal parsing code, which first checks that the nonterminal may begin with a given token:

https://github.com/rust-lang/rust/blob/ef71f1047e04438181d7cb925a833e2ada6ab390/compiler/rustc_parse/src/parser/nonterminal.rs#L47

In rust-lang#119099, `@fmease` implemented a change so that `const Tr` would be parsed as `dyn const Tr` (a trait object to a const trait) in edition 2015.

This is okay for the purposes of macros, because he explicitly made sure that `const` did not get added to the list of tokens that may begin a `:ty` nonterminal kind: rust-lang#119099 (comment)

However, since rustfmt is not so careful about eagerly parsing macro args before checking that they're legal in macro position, this changed the way that the string of tokens is being parsed into macro args.
@rustbot rustbot added the O-unix Operating system: Unix-like label Jan 22, 2024
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 22, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Jan 22, 2024

📌 Commit e153296 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 22, 2024
@bors
Copy link
Contributor

bors commented Jan 22, 2024

⌛ Testing commit e153296 with merge dbeb3ba...

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 22, 2024
…iaskrgr

Rollup of 11 pull requests

Successful merges:

 - rust-lang#117910 (Refactor uses of `objc_msgSend` to no longer have clashing definitions)
 - rust-lang#118639 (Undeprecate lint `unstable_features` and make use of it in the compiler)
 - rust-lang#119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in)
 - rust-lang#120058 (bootstrap: improvements for compiler builds)
 - rust-lang#120059 (Make generic const type mismatches not hide trait impls from the trait solver)
 - rust-lang#120097 (Report unreachable subpatterns consistently)
 - rust-lang#120137 (Validate AggregateKind types in MIR)
 - rust-lang#120164 (`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`)
 - rust-lang#120181 (Allow any `const` expression blocks in `thread_local!`)
 - rust-lang#120204 (Builtin macros effectively have implicit #[collapse_debuginfo(yes)])
 - rust-lang#120218 (rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job dist-i586-gnu-i586-i686-musl failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [debuginfo-gdb] tests/debuginfo/cross-crate-type-uniquing.rs ... ok

failures:

---- [debuginfo-gdb] tests/debuginfo/collapse-debuginfo-builtin.rs stdout ----
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 12001000

error: gdb failed to execute
status: exit status: 1
command: PYTHONPATH="/checkout/./src/etc" "/usr/bin/gdb" "-quiet" "-batch" "-nx" "-command=/checkout/obj/build/x86_64-unknown-linux-gnu/test/debuginfo/collapse-debuginfo-builtin.gdb/collapse-debuginfo-builtin.debugger.script"
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x2787: file /checkout/tests/debuginfo/collapse-debuginfo-builtin.rs, line 20.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, collapse_debuginfo_builtin::main () at /checkout/tests/debuginfo/collapse-debuginfo-builtin.rs:20
20     let ret = 0; // #break
hello world
[Inferior 1 (process 297395) exited normally]
--- stderr -------------------------------
--- stderr -------------------------------
/checkout/obj/build/x86_64-unknown-linux-gnu/test/debuginfo/collapse-debuginfo-builtin.gdb/collapse-debuginfo-builtin.debugger.script:12: Error in sourced command file:
No stack.



failures:

@bors
Copy link
Contributor

bors commented Jan 22, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 22, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-yn3hf5u branch March 16, 2024 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-unix Operating system: Unix-like rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.