forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Release 0.3.0
#7
Closed
Closed
Conversation
This file contains 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
While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby technically allowing it to be written to again. Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole categorically prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract). To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference.
…g you see on the page.
The `mir!` macro has multiple parts: - An optional return type annotation. - A sequence of zero or more local declarations. - A mandatory starting anonymous basic block, which is brace-delimited. - A sequence of zero of more additional named basic blocks. Some `mir!` invocations use braces with a "block" style, like so: ``` mir! { let _unit: (); { let non_copy = S(42); let ptr = std::ptr::addr_of_mut!(non_copy); // Inside `callee`, the first argument and `*ptr` are basically // aliasing places! Call(_unit = callee(Move(*ptr), ptr), ReturnTo(after_call), UnwindContinue()) } after_call = { Return() } } ``` Some invocations use parens with a "block" style, like so: ``` mir!( let x: [i32; 2]; let one: i32; { x = [42, 43]; one = 1; x = [one, 2]; RET = Move(x); Return() } ) ``` And some invocations uses parens with a "tighter" style, like so: ``` mir!({ SetDiscriminant(*b, 0); Return() }) ``` This last style is generally used for cases where just the mandatory starting basic block is present. Its braces are placed next to the parens. This commit changes all `mir!` invocations to use braces with a "block" style. Why? - Consistency is good. - The contents of the invocation is a block of code, so it's odd to use parens. They are more normally used for function-like macros. - Most importantly, the next commit will enable rustfmt for `tests/mir-opt/`. rustfmt is more aggressive about formatting macros that use parens than macros that use braces. Without this commit's changes, rustfmt would break a couple of `mir!` macro invocations that use braces within `tests/mir-opt` by inserting an extraneous comma. E.g.: ``` mir!(type RET = (i32, bool);, { // extraneous comma after ';' RET.0 = 1; RET.1 = true; Return() }) ``` Switching those `mir!` invocations to use braces avoids that problem, resulting in this, which is nicer to read as well as being valid syntax: ``` mir! { type RET = (i32, bool); { RET.0 = 1; RET.1 = true; Return() } } ```
The only non-obvious changes: - `building/storage_live_dead_in_statics.rs` has a `#[rustfmt::skip]` attribute to avoid reformating a table of data. - Two `.mir` files have slight changes involving line numbers. - In `unusual_item_types.rs` an `EMIT_MIR` annotation is moved to outside a function, which is the usual spot, because `tidy` complains if such a comment is indented. The commit also tweaks the comments in `rustfmt.toml`.
…=oli-obk rustfmt `tests/mir-opt` Continuing the work started in rust-lang#125759. Details in individual commit log messages. r? `@oli-obk`
… are unused, just the number of entries is checked. The indices will be used in a follow-up commit
…, r=BoxyUwU Avoid follow-up errors if the number of generic parameters already doesn't match fixes rust-lang#125604 best reviewed commit-by-commit
…huss ARM Target Docs Update Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents. Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.
Align `Term` methods with `GenericArg` methods, add `Term::expect_*` * `Term::ty` -> `Term::as_type`. * `Term::ct` -> `Term::as_const`. * Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc. I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is. r? types
…=petrochenkov Handle no values cfgs with `--print=check-cfg` This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values. The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value. So for `cfg(feature, values())` we would print `feature=`. I also added the missing tracking issue number in the doc. r? ```@petrochenkov```
…ket-impls, r=GuillaumeGomez rustdoc: add a regression test for a former blanket impl synthesis ICE Fixes rust-lang#119792 (also passes in rust-lang#125907 in case you were wondering). r? rustdoc
Remove stray "this"
Rollup of 8 pull requests Successful merges: - rust-lang#124486 (Add tracking issue and unstable book page for `"vectorcall"` ABI) - rust-lang#125504 (Change pedantically incorrect OnceCell/OnceLock wording) - rust-lang#125608 (Avoid follow-up errors if the number of generic parameters already doesn't match) - rust-lang#125690 (ARM Target Docs Update) - rust-lang#125750 (Align `Term` methods with `GenericArg` methods, add `Term::expect_*`) - rust-lang#125818 (Handle no values cfgs with `--print=check-cfg`) - rust-lang#125909 (rustdoc: add a regression test for a former blanket impl synthesis ICE) - rust-lang#125919 (Remove stray "this") r? `@ghost` `@rustbot` modify labels: rollup
This is done due to the inordinate amount of time it takes for a normal `macos-latest` runner to build the compiler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.