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

Automatic Rustup #4180

Merged
merged 16 commits into from
Feb 6, 2025
Merged

Automatic Rustup #4180

merged 16 commits into from
Feb 6, 2025

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented Feb 6, 2025

Please close and re-open this PR to trigger CI, then enable auto-merge.

pnkfelix and others added 16 commits February 3, 2025 12:53
These are hooks to:

  1. control whether contract checks are run
  2. allow 3rd party tools to intercept and reintepret the results of running contracts.
#[contracts::requires(...)]  + #[contracts::ensures(...)]

cc rust-lang/rust#128044

Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings  that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition,  building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).

Known issues:

 * My original intent, as described in the MCP (rust-lang/compiler-team#759) was   to have a rustc-prefixed attribute namespace (like   rustc_contracts::requires). But I could not get things working when I tried   to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it  is called `contracts::requires`.

 * Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
   * (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)

* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
rustdoc: clean up a bunch of ts-expected-error declarations in main

This mostly consists of handling potentially-null input and adding more global functions to the list of globals.

Follow-up for #136161
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1)

Part of #134001, follow-up to #136326, extracted from #134009.

This PR performs an arbitrary subset of the LLVM-C binding migrations from #134009, which should make it less tedious to review. The remaining migrations can occur in one or more subsequent PRs.
bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros

Follow-up to rust-lang/rust#136091 (comment).

- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and `trace!`, which `cfg(feature = "tracing")`-gates the underlying `tracing` macros. They expand to nothing if `"tracing"` feature is not enabled.
- This is not done for `span!` or `event!` because they can return span guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute proc-macro unless you use another attribute proc-macro to wrap that.

It's not *great*, because `tracing::instrument` and `tracing::{span,event}` can't be wrapped this way.

Can test locally with:

```bash
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap/
```

r? ``@onur-ozkan`` (or reroll)
…uillaumeGomez

rustdoc-json-types: Document that crate name isn't package name.

This wasn't clear from the docs before: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/.E2.9C.94.20Getting.20external.20crate.20names.20as.20defined. CC `@kpreid`

r? `@GuillaumeGomez`
rustdoc-book: Clean up section on `--output-format`

Followup to #134531. Tracking issues #76578 and #134529 I guess.

r? ``@GuillaumeGomez``
Mark `std::fmt::from_fn` as `#[must_use]`

While working on #135494 I managed to shoot my own foot a few times by forgetting to actually use the result of `fmt::from_fn`, so I think a `#[must_use]` could be appropriate!

Didn't have a good message to put in the attr so left it blank, still unstable so we can come back to it I guess?

cc #117729 (and a huge +1 for getting it stabilized, it's very useful IMHO)
Add tests for nested macro_rules edition behavior

This adds tests to check the behavior of how nested macro_rules definitions work across edition boundaries. This covers a change in behavior due to rust-lang/rust#133274.

See rust-lang/rust#135669
Rollup of 8 pull requests

Successful merges:

 - #128045 (#[contracts::requires(...)]  + #[contracts::ensures(...)])
 - #136263 (rustdoc: clean up a bunch of ts-expected-error declarations in main)
 - #136375 (cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1))
 - #136392 (bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros)
 - #136396 (rustdoc-json-types: Document that crate name isn't package name.)
 - #136405 (rustdoc-book: Clean up section on `--output-format`)
 - #136502 (Mark `std::fmt::from_fn` as `#[must_use]`)
 - #136509 (Add tests for nested macro_rules edition behavior)

r? `@ghost`
`@rustbot` modify labels: rollup
Upgrade elsa to the newest version.

This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows.

This was spawned from rust-lang/rust#135870 (comment)
Avoid calling the layout_of query in lit_to_const

We got all the information available locally
rustdoc: run css and html minifier at build instead of runtime

This way, adding a bunch of comments to the JS files won't make rustdoc slower.

Meant to address rust-lang/rust#136161 (comment)
rustdoc: use ThinVec for generic arg parts

This reduces the size of both these args, and of path segments, so should measurably help with memory use.
@rustbot rustbot closed this Feb 6, 2025
@rustbot rustbot reopened this Feb 6, 2025
@oli-obk oli-obk added this pull request to the merge queue Feb 6, 2025
Merged via the queue into master with commit a1e8277 Feb 6, 2025
7 checks passed
@oli-obk oli-obk deleted the rustup-2025-02-06 branch February 6, 2025 08:12
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.

5 participants