Conversation
| .. rubric:: Legality Rules | ||
|
|
There was a problem hiding this comment.
Was this deletion intentional?
There was a problem hiding this comment.
yeah, it was stray text... it's in a separate commit to make that clear
| the :t:`visibility` of the :t:`name` is the most permissive one. | ||
|
|
||
| :dp:`fls_sUhnfV62HJrb` | ||
| When using :t:`keyword` ``crate`` or :t:`keyword` ``$crate`` to import the current :t:`crate`, you must use a :t:`renaming` to define the :t:`binding` name. |
There was a problem hiding this comment.
Could you point me to the Reference PR or text where you took these rules from?
Regardless, since the FLS is not a tutorial, you should avoid expressions such as "you must" (who is "you"? the programmer, the author of the conforming tool, the assessor?).
There was a problem hiding this comment.
There was a problem hiding this comment.
These comments are blocking because the PR currently adds only part of the upstream keyword-import model. In particular, the existing self and super legality rules still conflict with the new restriction paragraphs, so the FLS would remain internally inconsistent after merge. The remaining comments cover precision of the extern-prelude wording, preservation of the $crate distinction, and changelog classification.
| the :t:`visibility` of the :t:`name` is the most permissive one. | ||
|
|
||
| :dp:`fls_sUhnfV62HJrb` | ||
| When :t:`keyword` ``crate`` or :t:`keyword` ``$crate`` is used to import the current :t:`crate`, a :t:`renaming` must be used to define the :t:`binding` name. |
There was a problem hiding this comment.
This still looks incomplete relative to the upstream self-import change. Earlier FLS paragraphs still encode the pre-rust-lang/rust#146972 behavior: fls_cw006jhlboa still requires a single-segment self use-path to appear only inside a nesting import, which rejects use self as name;, while fls_RUiFQ17bmRLt still allows unrenamed use self::{self}; when the import path prefix is non-empty.
After rust-lang/rust#146972, those move together: renamed current-module imports such as use self as name; are allowed, and unrenamed current-module imports like use self::{self}; are rejected.
Could this PR also update those earlier self paragraphs so the new restriction block and the older legality rules stay aligned? A minimal fix would be to loosen fls_cw006jhlboa for the renamed single-segment case and tighten fls_RUiFQ17bmRLt so the non-empty-prefix exception does not keep use self::{self}; valid.
Support:
rust-lang/rust#146972- Reference
items.use.restrictions.self-alias - Reference
rust-lang/reference#2136
| When :t:`keyword` ``crate`` or :t:`keyword` ``$crate`` is used to import the current :t:`crate`, a :t:`renaming` must be used to define the :t:`binding` name. | ||
|
|
||
| :dp:`fls_QGdeRTe0H1Uc` | ||
| When :t:`keyword` ``super`` is used to import a parent :t:`module`, a :t:`renaming` must be used to define the :t:`binding` name. |
There was a problem hiding this comment.
This new super rule still conflicts with the earlier path-legality rule. fls_7k88ypcgaoff currently allows a super segment only as the first segment or after another super, so the FLS still rejects self::super and self::super::super. Upstream now allows super after an initial self, and the Reference examples for this restriction explicitly include use self::super as parent3;.
Could this PR also relax fls_7k88ypcgaoff so super may follow an initial self, or otherwise carve out the same allowance for use paths, so the earlier path rules do not keep rejecting forms this paragraph is meant to document?
Support:
rust-lang/rust#146972- Reference
paths.qualifiers.super.allowed-positions - Reference
paths.qualifiers.super.repetition - Reference
items.use.restrictions.super-alias - Reference
rust-lang/reference#2136
| When :t:`keyword` ``super`` is used to import a parent :t:`module`, a :t:`renaming` must be used to define the :t:`binding` name. | ||
|
|
||
| :dp:`fls_aam34hsRmKU2` | ||
| An :t:`external prelude` cannot be imported. |
There was a problem hiding this comment.
This sentence reads too broadly. Rust 2021 still allows imports through extern-prelude crate names, such as use ::std::io;. The disallowed case is importing bare leading :: itself, for example use ::{self as root};.
As written, An external prelude cannot be imported. reads as though extern-prelude imports are disallowed wholesale.
Could this be restated in terms of :: as the extern-prelude root instead? If so, the earlier global-path rules probably also need a follow-on update so Rust 2021 no longer appears to permit ::self, ::super, ::crate, or ::$crate.
Support:
rust-lang/rust#146972- Reference
items.use.restrictions.extern-prelude - Reference
paths.qualifiers.global-root.edition2018 - Reference
rust-lang/reference#2136
| the :t:`visibility` of the :t:`name` is the most permissive one. | ||
|
|
||
| :dp:`fls_sUhnfV62HJrb` | ||
| When :t:`keyword` ``crate`` or :t:`keyword` ``$crate`` is used to import the current :t:`crate`, a :t:`renaming` must be used to define the :t:`binding` name. |
There was a problem hiding this comment.
$crate probably should not be folded into the same sentence as crate here. Earlier FLS text treats it as macro-specific in two ways: fls_774uryecc2sx only permits it within a macro transcriber, and fls_yrpem8vhxpr5 resolves it to the crate that defines the expanded macro. Grouping it under "used to import the current crate" makes $crate read like an ordinary spelling of crate, which is weaker than the current FLS model and the Reference's separate items.use.restrictions.macro-crate-alias rule.
Could this be split into separate crate and $crate restrictions, or reworded so the $crate half matches the existing FLS model and the Reference's separate items.use.restrictions.macro-crate-alias rule?
Support:
rust-lang/rust#146972- Reference
items.use.restrictions.macro-crate-alias - Reference
paths.qualifiers.macro-crate - Reference
rust-lang/reference#2136
| - :p:`fls_sUhnfV62HJrb` | ||
| - :p:`fls_QGdeRTe0H1Uc` | ||
| - :p:`fls_aam34hsRmKU2` | ||
| - :p:`fls_LV94x3HlpBWk` |
There was a problem hiding this comment.
I rechecked the pre-rust-lang/reference#2136 Reference snapshot, and the enum-variant-through-type-alias restriction was already present there as items.use.restrictions.variant. Since rust-lang/rust#146972 is specifically about keyword imports, adding fls_LV94x3HlpBWk under this Rust 1.95 language-change entry makes this look like an FLS correction rather than part of the 1.95 change itself.
Could this paragraph ID move out of the Support importing path-segment keywords with renaming entry and into the existing FLS corrections section instead, unless there is a stronger reason to tie it to rust-lang/rust#146972?
Support:
- Reference snapshot before
rust-lang/reference#2136already containsitems.use.restrictions.variant(rust-lang/reference@36016fc5164d3e10d0288e71f57c88dca937bd80) rust-lang/reference#2136rust-lang/rust#146972
4 participants
No description provided.