Skip to content
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
wants to merge 76 commits into from
Closed

Release 0.3.0 #7

wants to merge 76 commits into from

Conversation

ureeves
Copy link
Member

@ureeves ureeves commented Jun 3, 2024

No description provided.

pacak and others added 30 commits April 19, 2024 08:31
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.
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
jieyouxu and others added 25 commits June 4, 2024 08:25
…, 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
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.
Eduardo Leegwater Simões added 3 commits June 5, 2024 00:25
@ureeves ureeves closed this Jun 4, 2024
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.