The same should also be added to wrapping_div, wrapping_div_euclid and wrapping_rem_euclid.

Regression in https://github.com/rust-lang/rust/pull/114617, where the order of the variants of proc_macro::Spacing got changed.

MCVE: (playground)

extern crate proc_macro;

fn main() {
    assert_eq!(proc_macro::Spacing::Alone as u8, 0);
}

The watt crate is relying on the discriminant values here:

https://github.com/dtolnay/watt/blob/8dc8981c6c5c2a3e0ff6c9ec3830133538c78870/src/encode.rs#L108-L112

https://github.com/dtolnay/watt/blob/8dc8981c6c5c2a3e0ff6c9ec3830133538c78870/src/decode.rs#L117-L124

@rustbot label -E-needs-bisection -E-needs-mcve +S-has-mcve +A-proc-macros

struct P
{
    char i;
    float f;
} __packed__;

That's defining a global variable named __packed__ of type struct P. The correct syntax is

struct P
{
    char i;
    float f;
} __attribute__((__packed__));

The x86-64 psABI says

• If the size of an object is larger than eight eightbytes, or it contains unaligned fields, it has class MEMORY.
• If the class is MEMORY, pass the argument on the stack at an address respecting the arguments alignment (which might be more than its natural alignement).

Since the field f is unaligned, passing the value indirectly / on the stack is correct.

Format strings don't support raw identifiers (e.g. format!("{r#type}")), but they do support keywords in the format string directly (e.g. format!("{type}")). This PR improves the error output when attempting to use a raw identifier in a format string and adds a machine-applicable suggestion to remove the r#.

fixes https://github.com/rust-lang/rust/issues/115466

Identifiers in format strings are always "raw" and it will compile if you remove the r#:

fn main() {
    let r#type = "foobar";
    println!("It is {type}");
}

This is documented here:

• identifier is an IDENTIFIER_OR_KEYWORD (not an IDENTIFIER) as defined by the Rust language reference.

But the error should probably have a better diagnostic and a suggestion to remove the r#.

This PR fixes a few stack overflows by growing the stack in the appropriate places:

• in tcx.short_ty_string when generating the the full type name has been written to '...' diagnostic
• in tcx.resolve_vars_if_possible

fixes https://github.com/rust-lang/rust/issues/112800 fixes https://github.com/rust-lang/rust/issues/112992

I currently don't have a clean solution for https://github.com/rust-lang/rust/pull/112998#issuecomment-1620470071. That's a stack overflow in the destructor of ImplDerivedObligationCause that happens for very deeply nested obligations, but only on Windows for some reason.

I think the correct solution involves adding some actual interning to InternedObligationCauseCode, instead of just sticking it into an Rc.

For now, I'm gonna close this as "postponed".

related: https://github.com/rust-lang/rust/issues/113257

searched nightlies: from nightly-2023-05-13 to nightly-2023-08-13 regressed nightly: nightly-2023-05-24 searched commit range: https://github.com/rust-lang/rust/compare/8b4b20836b832e91aa605a2faf5e2a55190202c8...5ea3f0ae08c07472239a94ce55601e9b63eb1f45 regressed commit: https://github.com/rust-lang/rust/commit/f3d597b31c0f101a02c230798afa31a36bdacbc6 -> https://github.com/rust-lang/rust/pull/111807

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.6.6</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc --script script.sh -- build 

script.sh:

#!/bin/sh
rm -rf incr* && rustc src/main.rs --crate-name incr_comp_ice -C incremental=incr --cfg a && rustc src/main.rs --crate-name incr_comp_ice -C incremental=incr --cfg b

</details>

Reduced:

#![allow(dead_code)]

trait Query {
    type Value;
}

struct Slot<Q>
where
    Q: Query,
{
    state: std::cell::Cell<QueryState<Q>>,
}

enum QueryState<Q>
where
    Q: Query,
{
    InProgress(Q::Value),
    Memoized(Memo<Q>),
}

struct Memo<Q>
where
    Q: Query,
{
    value: Q::Value,
    inputs: Box<()>,
}

struct HirNodeQuery;

impl Query for HirNodeQuery {
    type Value = HirNode;
}

enum HirNode {
    A,
    #[cfg(a)]
    B(()),
}

fn conjure<T>() -> T {
    todo!()
}

fn main() {
    let slot = conjure::<Slot<HirNodeQuery>>();
    slot.state.set(conjure())
}

rustc src/main.rs --crate-name incr_comp_ice -C incremental=incr --cfg a
rustc src/main.rs --crate-name incr_comp_ice -C incremental=incr --cfg b

@rustbot label -E-needs-mcve +S-has-mcve +A-incr-comp

cargo bisect-rustc says this but I'm not sure I believe it:

Bisect points to https://github.com/rust-lang/rust/pull/109075, because that's where this TAIT pattern got added to std.

Bisecting the reduced example points me to https://github.com/rust-lang/rust/pull/112777.

<details>

Regression in https://github.com/rust-lang-ci/rust/commit/9cf74a0f380df8ffc43534bd52e8c35e16339873

searched nightlies: from nightly-2023-06-13 to nightly-2023-08-02 regressed nightly: nightly-2023-06-20 searched commit range: https://github.com/rust-lang/rust/compare/2d0aa57684e10f7b3d3fe740ee18d431181583ad...fe7454bf439c93cbe9ac8a8f7fcfacd5a40244c2 regressed commit: https://github.com/rust-lang/rust/commit/fe7454bf439c93cbe9ac8a8f7fcfacd5a40244c2

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.6.6</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc -- rustc -- -Z validate-mir 

</details>

</details>

Reduced:

// crate foo

#![feature(type_alias_impl_trait)]

type Tait = impl Sized;

#[allow(dead_code)]
fn constrain() -> Tait {}

struct WrapperWithDrop<T>(T);
impl<T> Drop for WrapperWithDrop<T> {
    fn drop(&mut self) {}
}

pub struct Foo(WrapperWithDrop<Tait>);

// crate bar

pub fn drop_foo(_: foo::Foo) {}

@rustbot label F-type_alias_impl_trait

fn deref_partially_dangling() {
    let x = (1, 13);
    let xptr = &x as *const _ as *const (i32, i32, i32);
    let val = unsafe { (*xptr).1 };
    assert_eq!(val, 13);
}

Have we decided that the order of the fields in the tuple (i32, i32, i32) is guaranteed? In the UCG it specifically says that tuple fields can be reordered, such that .1 could actually be the third field in memory and out-of-bounds.

Wouldn't that cause an infinite loop in the current implementation of find_ancestor_in_same_ctxt and find_ancestor_inside? To me the logic in macro_backtrace looks like it's just deduplicating the backtrace for self-recursive macro calls, not doing any kind of cycle check.

We could have a new method find_ancestor_inside_same_ctxt that would call find_ancestor_in_same_ctxt and then also check that the spans overlap. I think that should be semantically equal to your first suggestion, because the chain of ctxts can't be cyclic? The new method would then be used instead of find_ancestor_inside where the span needs to be joined.

reduced LLVM IR: https://godbolt.org/z/Yncqrjfr7

define void @foo(ptr noalias byval(i64) %x) {
start:
  %new_x = alloca i64, align 8
  %x_val = load i64, ptr %x, align 8
  %is_zero = icmp eq i64 %x_val, 0
  br i1 %is_zero, label %end, label %recurse

recurse:
  store i64 0, ptr %new_x, align 8
  call void @foo(ptr %new_x)
  br label %end

end:
  ret void
}

optimizes to

define void @foo(ptr noalias nocapture readonly byval(i64) %x) {
  %x_val = load i64, ptr %x, align 8
  %is_zero = icmp eq i64 %x_val, 0
  br i1 %is_zero, label %end, label %recurse

recurse:
  br label %recurse

end:
  ret void
}

Needs noalias + byval to reproduce. Looks like the tail call optimization pass writes into the argument, even thou it is readonly at that point.

Did not bisect, but this was probably introduced by the upgrade to LLVM 16: https://github.com/rust-lang/rust/pull/109474

@rustbot label A-llvm I-unsound

Yes, that's correct, disregard my comment.

This could also have a specialization for dyn Write itself:

        impl SpecWriteFmt for &mut (dyn Write + '_) {
            #[inline]
            fn spec_write_fmt(self, args: Arguments<'_>) -> Result {
                write(self, args)
            }
        }

... and probably dyn Write + Send and dyn Write + Send + Sync as well, because those are considered different types for the sake of specialization.