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

Rollup of 8 pull requests #136564

Merged
merged 32 commits into from
Feb 5, 2025
Merged

Rollup of 8 pull requests #136564

merged 32 commits into from
Feb 5, 2025

Conversation

fmease
Copy link
Member

@fmease fmease commented Feb 5, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Zalathar and others added 30 commits February 1, 2025 13:34
The LLVM-C binding takes an explicit context, whereas our binding obtained the
context from the scope argument.
This mostly consists of handling potentially-null input and adding
more global functions to the list of globals.
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.
… to invoke.

see test for an example of the kind of injected code that is anticipated here.
…ract lang items

includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.

includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.

includes post-developed commit, placating rustfmt self dogfooding.

includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/

includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).

Rebase Conflicts:
 - compiler/rustc_parse/src/parser/diagnostics.rs
 - compiler/rustc_parse/src/parser/item.rs
 - compiler/rustc_span/src/hygiene.rs

Remove contracts keywords from diagnostic messages
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#133274.

See rust-lang#135669
Check ensures on early return due to Try / Yeet

Expand these two expressions to include a call to contract checking
The extended syntax for function signature that includes contract clauses
should never be user exposed versus the interface we want to ship
externally eventually.
Instead of parsing the different components of a function signature,
eagerly look for either the `where` keyword or the function body.

- Also address feedback to use `From` instead of `TryFrom` in cranelift
  contract and ubcheck codegen.
1. Document the new intrinsics.
2. Make the intrinsics actually check the contract if enabled, and
   remove `contract::check_requires` function.
3. Use panic with no unwind in case contract is using to check for
   safety, we probably don't want to unwind. Following the same
   reasoning as UB checks.
This is now a valid expected value.
This has now been approved as a language feature and no longer needs
a `rustc_` prefix.

Also change the `contracts` feature to be marked as incomplete and
`contracts_internals` as internal.
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and
  `trace!`, which `cfg(feature = "tracing")`-gates the underlying
  `tracing` macros.
- 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.
#[contracts::requires(...)]  + #[contracts::ensures(...)]

cc rust-lang#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.
…=fmease

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 rust-lang#136161
…gjubilee

cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1)

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

This PR performs an arbitrary subset of the LLVM-C binding migrations from rust-lang#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#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)
…hyyy, r=GuillaumeGomez

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`
…iddle

rustdoc-book: Clean up section on `--output-format`

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

r? ``@GuillaumeGomez``
… r=dtolnay

Mark `std::fmt::from_fn` as `#[must_use]`

While working on rust-lang#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 rust-lang#117729 (and a huge +1 for getting it stabilized, it's very useful IMHO)
…r=jieyouxu

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#133274.

See rust-lang#135669
@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 5, 2025
@fmease
Copy link
Member Author

fmease commented Feb 5, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 5, 2025

📌 Commit c20a58d has been approved by fmease

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 5, 2025
@bors
Copy link
Contributor

bors commented Feb 5, 2025

⌛ Testing commit c20a58d with merge 07179d5...

@bors
Copy link
Contributor

bors commented Feb 5, 2025

☀️ Test successful - checks-actions
Approved by: fmease
Pushing 07179d5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 5, 2025
@bors bors merged commit 07179d5 into rust-lang:master Feb 5, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Feb 5, 2025
@fmease fmease deleted the rollup-qcjjcm7 branch February 5, 2025 10:15
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#128045 #[contracts::requires(...)] + #[contracts::ensures(...)] 580efdee0d09197e14bf69ade8eb311305989ab6 (link)
#136263 rustdoc: clean up a bunch of ts-expected-error declarations… 777f19f05a2009d6913d914f81d63443694bdd5b (link)
#136375 cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bi… 0efe609166333489497277910ba57d82d78abec9 (link)
#136392 bootstrap: add wrapper macros for feature = "tracing"-gat… 259812fcfc49719d9a8c3e67730d918bfac2e70e (link)
#136396 rustdoc-json-types: Document that crate name isn't package … bdffae1ca3858fe80eccd9c1aa02b54d9a33885d (link)
#136405 rustdoc-book: Clean up section on --output-format bf5d404781a80a61e7c5cf4a6e4bac02588c80db (link)
#136502 Mark std::fmt::from_fn as #[must_use] eafa13dafca1d3b35954a978ea010748f0b10a47 (link)
#136509 Add tests for nested macro_rules edition behavior 7b73bc2a9f5aabaa5b9c04650a0f15fb3e0e4887 (link)

previous master: 8df89d1cb0

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (07179d5): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
0.2% [0.2%, 0.2%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.3% [-0.3%, -0.3%] 2
All ❌✅ (primary) 0.2% [0.2%, 0.2%] 2

Max RSS (memory usage)

Results (primary -0.1%, secondary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
1.3% [0.4%, 2.7%] 4
Regressions ❌
(secondary)
1.3% [0.7%, 2.5%] 5
Improvements ✅
(primary)
-5.7% [-5.7%, -5.7%] 1
Improvements ✅
(secondary)
-2.5% [-4.0%, -1.5%] 4
All ❌✅ (primary) -0.1% [-5.7%, 2.7%] 5

Cycles

Results (primary -2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.5% [-2.5%, -2.5%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.5% [-2.5%, -2.5%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 776.632s -> 779.293s (0.34%)
Artifact size: 328.78 MiB -> 328.78 MiB (0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustdoc-json Area: Rustdoc JSON backend merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.