Skip to content

Conversation

@tshepang
Copy link
Member

No description provided.

bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 11, 2025
1826: FLS: Rust 1.89 and 1.90 updates r=Hoverbear a=tshepang

This includes these upstream changes:

- rust-lang/fls#579
- rust-lang/fls#580

Also included are some text fixes not strictly related to Rust compiler changes.

Co-authored-by: Tshepang Mbambo <tshepang.mbambo@ferrous-systems.com>
bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 11, 2025
1826: FLS: Rust 1.89 and 1.90 updates r=Hoverbear a=tshepang

This includes these upstream changes:

- rust-lang/fls#579
- rust-lang/fls#580

Also included are some text fixes not strictly related to Rust compiler changes.

Co-authored-by: Tshepang Mbambo <tshepang.mbambo@ferrous-systems.com>
bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 11, 2025
1826: FLS: Rust 1.89 and 1.90 updates r=Hoverbear a=tshepang

This includes these upstream changes:

- rust-lang/fls#579
- rust-lang/fls#580

Also included are some text fixes not strictly related to Rust compiler changes.

Co-authored-by: Tshepang Mbambo <tshepang.mbambo@ferrous-systems.com>
@traviscross
Copy link
Contributor

traviscross commented Oct 12, 2025

cc @PLeVasseur @nikomatsakis @joshtriplett

@tshepang tshepang force-pushed the tshepang/document-1.90 branch from a2ae9bd to a9fdd2d Compare October 16, 2025 13:24
Comment on lines 315 to 319
* :dp:`fls_zyuxqty09SDO`
All forms of :t:`[borrow]s` except those of expressions that would be subject to
:t:`drop scope extension`,
and which are either :t:`[mutable borrow]s`
or borrows of expressions that result in values with :t:`interior mutability`.
Copy link
Contributor

@traviscross traviscross Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things. One, it's OK for the expression to be subject to drop scope extension. It's not OK for that extension to extend the scope outside of the initializer to the end of the program.

const _: () = { let x = { &mut 0u8 }; x; }; //~ OK
//                             ^^^
// The drop scope of this temporary is extended.

Two, the comma in "..., and which are either..." causes me to read it as a clause independent from "except...". I.e., this says (applying commutativity) "all forms of borrows 1) that are either mutable or result in values with interior mutability and 2) where the expression would not be subject to drop scope extension".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@traviscross -- did this address the issue raised?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is correct, except that, if I'm reading the diff correctly, it's putting this language in the list of what constitutes a constant context rather than about what constitutes a constant expression. We're defining constant expressions here, and the existing rules about "borrows" and "immutable borrow expressions" will need to be changed (and then that reflected in the changelog, etc.).

Comment on lines +98 to +100
:dp:`fls_ooOYxhVh8hZo`
The type of a :t:`constant` cannot be a :t:`mutable reference type`.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things. One, even with the other rule, this needs to talk about containing a mutable reference rather than being one.

Two, it's not enough to talk about types here. We actually do this reasoning by value, not by type.

trait Tr {}
impl<T: ?Sized> Tr for T {}
static mut X: u8 = 0;
const _: &dyn Tr = unsafe { &&mut X }; //~ ERROR
//       ^^^^^^^
// This type does not contain any mutable references.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

am not sure how to word this simply, given the complexities

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will give this a shot.

The paragraph

The type of a :t:constant cannot be a :t:mutable reference type.

should be removed.

Insert the following after
7.1:8 The value of a constant is determined by evaluating its constant initializer.

The value of a constant cannot contain any mutable references, except when:

  • The type of the constant is an immutable reference and the initializer contains a reference to a mutable static, or
  • The type of the constant is subject to interior mutability and the initializer contains a reference to a value subject to interior mutability, or
  • The type of the constant is a zero-sized type and the initializer contains a reference to a value of a zero-sized type, or
  • The initializer contains a reference to an external static.

I am not sure whether the type of the constant plays a role in the external static case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The value of a constant cannot contain any mutable references, except when... The initializer contains a reference to an external static.

unsafe extern "C" {
    safe static S1: u8;
}

static mut S2: u8 = 0;

const C: (&u8, &mut u8) = (&S1, unsafe { &mut S2 }); //~ ERROR
//                         ^^^
// The initializer contains a reference to an external static.

Copy link
Contributor

@traviscross traviscross Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly:

The value of a constant cannot contain any mutable references, except when... The type of the constant is an immutable reference and the initializer contains a reference to a mutable static...

static mut S1: u8 = 0;
static mut S2: u8 = 0;

const C: &(&u8, &mut u8) = unsafe { &(&S1, &mut S2) }; //~ ERROR
//       ^                            ^^^
// The type of the constant is an immutable reference and the
// initializer contains a reference to a mutable static.

Copy link
Contributor

@traviscross traviscross Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second case is the one I mean. Agreed it's illegal. What rule are we suggesting makes it illegal?

My reading is that this language, by itself, would allow it:

The final value of a constant, after the constant initializer is evaluated to a value of the declared type, cannot contain any mutable references except when... The referent is subject to interior mutability...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps

The final value of a constant, after the constant initializer is evaluated to a value of the declared type, cannot contain any mutable references except when...

  • The type of the constant is an immutable reference and the referent is subject to interior mutability, or ...

Assuming the above is correct, the full set of rules becomes

The final value of a constant, after the constant initializer is evaluated to a value of the declared type, cannot contain any mutable references except when

  • The mutable reference is successfully coerced to an immutable reference, or
  • The mutable reference is contained within an external static, or
  • The mutable reference is contained within an union, or
  • The type of the constant is an immutable reference and the referent is subject to interior mutability, or
  • The referent is of a zero-sized type.

🙏

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The final value of a constant, after the constant initializer is evaluated to a value of the declared type, cannot contain any mutable references except when... The type of the constant is an immutable reference and the referent is subject to interior mutability, or ...

This does actually happen to be true, in one particular case:

#![allow(static_mut_refs)]
use core::cell::UnsafeCell;
struct W<T>(UnsafeCell<T>);
unsafe impl<T> Sync for W<T> {}

static S: W<&mut u8> = {
    static mut I: u8 = 0; W(UnsafeCell::new(unsafe { &mut I }))
};

const _: &W<&mut u8> = &S;

Good catch there. I don't think the Reference actually covers this. I've asked @RalfJung and @oli-obk about this.

Of course, one does have to consider this in the context of the rules for valid constant expressions, which include:

r[const-eval.const-expr.borrows]

  • All forms of [borrow]s, including raw borrows, except borrows of expressions whose temporary scopes would be extended (see [temporary lifetime extension]) to the end of the program and which are either:
    • Mutable borrows.
    • Shared borrows of expressions that result in values with [interior mutability].

That is, one can't simply write const _: .. = &Cell::new(..).

However, the statement is not general enough, as we also accept similar cases where the type of the constant itself is not an immutable reference.

#![allow(static_mut_refs)]
use core::cell::UnsafeCell;
struct W<T>(UnsafeCell<T>);
unsafe impl<T> Sync for W<T> {}

static S: W<&mut u8> = {
    static mut I: u8 = 0; W(UnsafeCell::new(unsafe { &mut I }))
};

struct Outer<T>(T);

const _: Outer<&W<&mut u8>> = Outer(&S);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More generally, in this and other cases, I might suggest that we try to use verbiage that is as close as possible to the relevant rules in the Reference (i.e., trying to adjust only as minimally as possible for style). (And if we think the phrasing in the Reference can be improved, making that PR first.)

Doing this would seem best to help align the documents and to minimize the correctness-checking effort on the FLS side. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

S in these examples is a mutable static, i.e. a static whose backing store permits mutation. So we can't recurse into it for const validation purposes (and it'd make little sense since the data there may change so even if it's valid now, it might become invalid later).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants