Document name resolution #17
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
specify s390x target features
Having just "Struct" as the link makes it look like the target is about structs and not just struct expressions
yaahc
force-pushed
the
name-res
branch
6 times, most recently
from
37a2c73 to
a8b8581
Compare
const_eval.md: be more clear where link leads to
These don't really belong where they are, and are just generally helpful things about the attribute.
The current text was a little bit of a mess and had some subtle inaccuracies. This reworks so that the intro follows the template, and just generally introduces the attribute. `allowed-positions` now just specifies the allowed positions. I reworked the behavior changes caused by no_std into proper separate rules. `std` is not injected into the crate root anymore starting with edition 2018.
I do not know how this was missing, I've looked at it a million times. I feel like I was maybe missing something, but I really can't find anything that directly refers to this, nor can I find any open issues. I believe this is now done with this relatively subtle bit: https://github.com/rust-lang/rust/blob/4d08223c054cf5a56d9761ca925fd46ffebe7115/compiler/rustc_builtin_macros/src/standard_library_imports.rs#L42 In the past it used to use a different approach of emulating `extern crate std as _;`: https://github.com/rust-lang/rust/blob/c8cf9f5a025bb475804b5a90f54aca310b952526/src/libsyntax_ext/standard_library_imports.rs#L42-L46
More closely align with the template, and some minor word tweaks.
We had said here that the `no_std` attribute is used to "prevent the automatic linking of the std crate", but then further down we say, "using `no_std` does not prevent the standard library from being linked in". The important distinction here is the word "automatically", but that gets a bit lost due to reusing the "prevent" phrasing. Probably "prevent" is just too strong a word to use when what we're really saying is that we're causing something to not happen automatically. Let's make that more clear and increase sentence parallelism.
Some sentences here could be improved with more sentence parallelism and a bit of reordering, so let's do that.
We had text in the intro about "deferring to the core crate instead", but it may not have been sufficiently clear what we mean exactly by that. Let's talk specifically about how `no_std` causes us to use the `core` crate for the standard library prelude and for the `macro_use` prelude.
We want to highlight how using `no_std` doesn't prevent `std` from being linked. Let's revise and elaborate this text for clarity.
The text here could be read in such a way as to imply that `no_std` affected whether or not `core` was added to the extern prelude, but that isn't the case. Let's make it clear that this section is about what is added to the `macro_use` prelude and speak to that directly.
Update `no_std` to use the attribute template
This test is believed to fail, so we should mark it with `compile_fail` rather than `ignore`. Let's wrap the comment. The compiler's error message, in this case, doesn't add any insight; let's remove the details of that.
The sentence "Other attributes are parsed but rejected" has a two-part
compound predicate; that is, the subject is used for two verbs,
separated by a coordinating conjunction ("but"), and is not repeated.
In these cases, a comma is omitted before the coordinating
conjunction, so let's remove the comma.
We have a list that describes where attributes may be applied. We're adding inline assembly template strings and operands to that list, but only certain attributes may be used, and other caveats apply. Let's note that there are restrictions and link to the relevant section for more details, as we do already for certain other items on this list. It may be important, normatively, to note this restriction here if we now or later refer to some attribute as being accepted anywhere that attributes are allowed.
The implementation of attributes for asm macro template strings and operands doesn't use the normal system in `rustc` for handling attributes. This leads to the limitations and may lead to subtle divergences in behavior. Let's make a note about this. For background, see: - rust-lang/reference#2063 (comment) - rust-lang/rust#147736 (comment)
add 'system' to variadic ABIs
We had said that the dereference operator could not be used with raw pointers in a constant expression. However, that restriction has been lifted. First, in Rust 1.58, we stabilized `const_raw_ptr_deref`. rust-lang/rust#89551 This allowed for dereferencing immutable raw pointers in a constant expression. Then, in Rust 1.83, we stabilized `const_mut_refs` and `const_refs_to_cell`. rust-lang/rust#129195 That allowed for: - Mentioning `&mut` types. - Creating `&mut` and `*mut` values. - Creating `&T` and `*const T` values where `T` contains interior mutability. - Dereferencing `&mut` and `*mut` values (both for reads and writes). Let's remove the stated restriction on dereferencing raw pointers in a constant expression and add examples.
To define what's allowed in a constant expression, we have a list that starts with the text: > The following expressions are constant expressions... Correspondingly, most of the items in this list are stated in terms of being a "this expression" or a "that expression". However, for deref, we had instead said "the dereference operator". Even though the `expr.deref` section is currently titled "the dereference operator", it seems more clear and consistent in the context of this list to talk about dereference expressions, so let's do that. These are expressions, after all, The grammar production is named `DereferenceExpression`. (There is one other place in the list that we talk about operators: "built-in negation, arithmetic, logical, comparison, or lazy boolean operators used on integer and floating point types, `bool`, and `char`." Perhaps we'll reword that one later. It stands out a bit less than this one did.)
…ferencing-pointers-in-const Remove restriction on dereferencing pointers in const
This text is great. Jane put this together after talking with the team in some detail in a lang-docs office hours call. In this commit, we revise the wording slightly and adjust capitalization to match our style.
Add review process overview to review-policy.md
remove unused "link reference definitions"
document `cfg` conditions on inline assembly templates and operands
use oxford comma
The rule is that "mutable references contained within a mutable static may be referenced in the final value of a constant." However, the key here is that "mutable static" means either a `static mut` item or a `static` item with an interior mutable type. We had made that clear over in `const-eval.const-expr.path-static` but not in our rules about const item validity, and our link for "mutable static" had implied it may mean `static mut`. Let's fix that and add an example to demonstrate the point.
These link reference definitions were used in `const.no-mut-refs` and are no longer needed.
get rid of const.no-mut-refs
Update to mdbook 0.5
Co-authored-by: Vadim Petrochenkov <[email protected]> Co-authored-by: Eric Huss <[email protected]> Co-authored-by: Tshepang Mbambo <[email protected]>
Co-authored-by: Eric Huss <[email protected]> Co-authored-by: TC
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
copy of rust-lang/reference#2055 for inclusion in reference expansion demo copy