-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Rollup of 8 pull requests #136564
Conversation
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.
- 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
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 8df89d1cb0 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (07179d5): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis 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.
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.
CyclesResults (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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 776.632s -> 779.293s (0.34%) |
Successful merges:
feature = "tracing"
-gatedtracing
macros #136392 (bootstrap: add wrapper macros forfeature = "tracing"
-gatedtracing
macros)--output-format
#136405 (rustdoc-book: Clean up section on--output-format
)std::fmt::from_fn
as#[must_use]
#136502 (Markstd::fmt::from_fn
as#[must_use]
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup