Rollup of 9 pull requests #136531
Closed
Rollup of 9 pull requests #136531
+2,698
−574
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
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
…ostcondition predicate.
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.
This trait doesn't appear to provide any benefit over a simple helper function.
- 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)
…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`
Report generic mismatches when calling bodyless trait functions Don't know if there's an open issue for this. Just happened to notice this when working in that area. The awkward extra spans added to the diagnostics of some tests (e.g. `trait-with-missing-associated-type-restriction`) is consistent with what happens for normal functions. Should probably be removed since that span doesn't seem to note anything useful. First and third commit are both cleanups removing some unnecessary work. Second commit has the actual fix. fixes rust-lang#135124
… 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
mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers` A combination of two loosely-related tweaks that would otherwise conflict with each other: - `Cx` is a pretty unhelpful type name, especially when jumping between THIR-building and MIR-building while trying to make changes to THIR data structures. - The `UserAnnotatedTyHelpers` trait doesn't appear to provide any benefit over a simple helper function, and its `tcx()` method is currently completely unnecessary. No functional change.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 4, 2025
Rollup of 9 pull requests Successful merges: - rust-lang#128045 (#[contracts::requires(...)] + #[contracts::ensures(...)]) - rust-lang#136263 (rustdoc: clean up a bunch of ts-expected-error declarations in main) - rust-lang#136375 (cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1)) - rust-lang#136392 (bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros) - rust-lang#136405 (rustdoc-book: Clean up section on `--output-format`) - rust-lang#136497 (Report generic mismatches when calling bodyless trait functions) - rust-lang#136502 (Mark `std::fmt::from_fn` as `#[must_use]`) - rust-lang#136509 (Add tests for nested macro_rules edition behavior) - rust-lang#136526 (mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`) r? `@ghost` `@rustbot` modify labels: rollup
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
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.
Successful merges:
feature = "tracing"-gatedtracingmacros #136392 (bootstrap: add wrapper macros forfeature = "tracing"-gatedtracingmacros)--output-format#136405 (rustdoc-book: Clean up section on--output-format)std::fmt::from_fnas#[must_use]#136502 (Markstd::fmt::from_fnas#[must_use])thir::cx::CxtoThirBuildCxand removeUserAnnotatedTyHelpers#136526 (mir_build: Renamethir::cx::CxtoThirBuildCxand removeUserAnnotatedTyHelpers)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup