-
Notifications
You must be signed in to change notification settings - Fork 358
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
Automatic Rustup #4180
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
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.
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.
Please close and re-open this PR to trigger CI, then enable auto-merge.