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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Comment on lines 28 to 30
- `Allow constants whose final value has references to mutable/external memory, but reject such constants as patterns <https://github.com/rust-lang/rust/pull/140942>`_

- New paragraph: :p:`fls_wJ9f906BlBvg`
Copy link
Contributor

Choose a reason for hiding this comment

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

Do I read things correctly that we don't need to relax the legality rules for constants in 7.1 because they already did not state the restriction against references to mutable places? (Should the changelog say that?)

Similarly, there's no legality rule in 7.1 restricting against mutable references in the final value of a constant. Is that leaning instead on the rule in chapter 6, fls_ox6sgl9n43g2, that:

It is a static error to create a :t:mutable reference in a :t:constant context.

?

Note, however, that rule is wrong:

const _: () = { _ = &mut 0; () }; // OK

Copy link
Contributor

Choose a reason for hiding this comment

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

Similarly, are we missing the rule against shared references to interior mutable lifetime-extended temporaries in the final value of a constant?

Choose a reason for hiding this comment

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

@traviscross -- by:

Similarly, are we missing the rule against shared references to interior mutable lifetime-extended temporaries in the final value of a constant?

You refer here to this portion of the Reference, inside the Note?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Do I read things correctly that we don't need to relax the legality rules for constants in 7.1 because they already did not state the restriction against references to mutable places? (Should the changelog say that?)

oh, indeed, the changelog can say that

Similarly, there's no legality rule in 7.1 restricting against mutable references in the final value of a constant. Is that leaning instead on the rule in chapter 6, fls_ox6sgl9n43g2, that:

It is a static error to create a :t:mutable reference in a :t:constant context.

?

Note, however, that rule is wrong:

const _: () = { _ = &mut 0; () }; // OK

let me submit a change fixing this

Copy link
Member Author

@tshepang tshepang Oct 16, 2025

Choose a reason for hiding this comment

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

@traviscross
Copy link
Contributor

traviscross commented Oct 12, 2025

cc @PLeVasseur @nikomatsakis @joshtriplett

:t:`constant`, the :t:`type` of the :t:`associated constant` or :t:`constant`
shall be :t:`structurally equal`.

:dp:`fls_wJ9f906BlBvg`

Choose a reason for hiding this comment

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

Adding some traceability here to the Reference PR portion which means the FLS need be updated.

Copy link
Member Author

Choose a reason for hiding this comment

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

what is meant by "need be updated"

@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 318
:dp:`fls_ox6sgl9n43g2`
It is a static error to create a :t:`mutable reference` in a
:t:`constant context`.

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems like this should be added to the changelog.

Also, removing this rule without making other changes makes the FLS wrong in a different way, which is that I didn't see a rule elsewhere prohibiting a mutable reference in the final value of a constant.

Copy link
Member Author

Choose a reason for hiding this comment

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

it is added to changelog on a9fdd2d

am working on adding the other rule

Copy link
Member Author

Choose a reason for hiding this comment

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

af19a30

not too sure about the wording, if it says enough

src/values.rst Outdated
Comment on lines 98 to 99
:dp:`fls_ox6sgl9n43g2`
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.

This doesn't cover it.

struct W<T>(T);
const _: W<&mut ()> = W(&mut ()); //~ ERROR
const _: W<&AtomicU8> = W(&AtomicU8::new(0)); //~ ERROR

Copy link
Member Author

Choose a reason for hiding this comment

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

to be clear, are those additional rules

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.

What I'm getting at here specifically is that the final value can't contain any mutable references, not just that it can't be a mutable reference type.

struct W<T>(T);
static mut S: u8 = 0;
const _: W<&mut u8> = W(unsafe { &mut S }); //~ ERROR
//       ^^^^^^^^^^ Not a mutable reference type.

And then, yes, there are additional rules that prohibit mutable borrows of lifetime-extended temporaries even when that doesn't result in a mutable reference being contained in the final value.

struct W<T>(T);
const _: W<&u8> = W(&mut 0); //~ ERROR

Copy link
Member Author

Choose a reason for hiding this comment

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

at attempt 00c1bfd

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".

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.

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.

3 participants