-
Notifications
You must be signed in to change notification settings - Fork 38
document Rust 1.90 changes #580
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
base: main
Are you sure you want to change the base?
Conversation
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]>
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]>
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]>
src/changelog.rst
Outdated
- `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` |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes; normatively it's stated in https://doc.rust-lang.org/nightly/reference/const_eval.html#r-const-eval.const-expr.borrows.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:t:`constant`, the :t:`type` of the :t:`associated constant` or :t:`constant` | ||
shall be :t:`structurally equal`. | ||
|
||
:dp:`fls_wJ9f906BlBvg` |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"
a2ae9bd
to
a9fdd2d
Compare
:dp:`fls_ox6sgl9n43g2` | ||
It is a static error to create a :t:`mutable reference` in a | ||
:t:`constant context`. | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not too sure about the wording, if it says enough
src/values.rst
Outdated
:dp:`fls_ox6sgl9n43g2` | ||
The type of a :t:`constant` cannot be a :t:`mutable reference type`. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at attempt 00c1bfd
* :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`. |
There was a problem hiding this comment.
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".
:dp:`fls_ooOYxhVh8hZo` | ||
The type of a :t:`constant` cannot be a :t:`mutable reference type`. | ||
|
There was a problem hiding this comment.
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.
No description provided.