Pull upstream master 2023 10 18 #57
Merged
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
This add a new form and deprecated the other ones:
- cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))
- cfg(name1, ..., nameN) or cfg(name1, ..., nameN, values())
- cfg(any())
It also changes the default exhaustiveness to be enable-by-default in
the presence of any --check-cfg arguments.
When encountering method call chains of `Iterator`, check for trailing `;` in the body of closures passed into `Iterator::map`, as well as calls to `<T as Clone>::clone` when `T` is a type param and `T: !Clone`. Fix #9082.
(some powerpc64le targets can guarantee more, but for now it doesn't seem worth separating by OS/vendor)
Also add a few methods to instantiate instances and get an instance definition. We're still missing support to actually monomorphize the instance body.
Updated libc and doc for Vita target Doc changes: - Updated Vita target readme. The recommended approach to build artifacts for the platform now is [cargo-vita](https://crates.io/crates/cargo-vita) which wraps all the convoluted steps previously described in a yaml for `cargo-make` - Updated maintainer list for Vita target. (`@ZetaNumbers` `@pheki` please agree to be added to the list, `@amg98` please let us know if you're still planning on actively maintaining target support) Code changes: - ~Updated libc for rust-lang/libc#3284 and rust-lang/libc#3366~ (Already merged in #116527) - In dupfd changed the flag same as for esp target, there is no CLOEXEC on Vita - Enabled `new_pair` since we've implemented `socketpair` in Vita newlib
Duplicate `~const` bounds with a non-const one in effects desugaring This should unblock #116058. r? `@oli-obk`
document when atomic loads are guaranteed read-only Based on this [discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Can.20.60Atomic*.3A.3Aload.60.20perform.20a.20write). The values for x86 and x86_64 are complete guesswork on my side, and I have no clue what the values might be for other architectures. I hope we can get the right people to chime in to gather the required information. :) I'll update Miri to respect these rules once we have more data.
Update cargo 17 commits in 6fa6fdc7606cfa664f9bee2fb33ee2ed904f4e88..ff768b45b302efd488178b31b35489e4fabb8799 2023-10-10 23:06:08 +0000 to 2023-10-17 12:51:31 +0000 - Clarify flag behavior in `cargo remove --help` (rust-lang/cargo#12823) - doc(cargo-login): mention args after `--` in manpage (rust-lang/cargo#12832) - changelog: add compat notice for `cargo login -- <arg>` (rust-lang/cargo#12830) - update SPDX License info (rust-lang/cargo#12827) - Add test for `-V` short argument (rust-lang/cargo#12822) - add detailed message when target folder path is invalid (rust-lang/cargo#12820) - chore(deps): update rust crate toml_edit to 0.20.2 (rust-lang/cargo#12761) - Support `public` dependency configuration with workspace deps (rust-lang/cargo#12817) - Update rustix to 0.38.18 (rust-lang/cargo#12815) - contrib docs: add some conveniences (rust-lang/cargo#12812) - Better suggestion for unsupported `--path` flag (rust-lang/cargo#12811) - contrib docs: update rfc and roadmap links (rust-lang/cargo#12814) - contrib doc: remove extraneous word (rust-lang/cargo#12813) - Update curl-sys to pull in curl 8.4.0 (rust-lang/cargo#12808) - feat: add package name and version to warning messages (rust-lang/cargo#12799) - Do not call it "Downgrading" when difference is only build metadata (rust-lang/cargo#12796) - Add unsupported short flag suggestion for `--target` and `--exclude` flags (rust-lang/cargo#12805) r? ghost
Add new simpler and more explicit syntax for check-cfg <details> <summary> Old proposition (before the MCP) </summary> This PR adds a new simpler and more explicit syntax for check-cfg. It consist of two new form: - `exhaustive(names, values)` - `configure(name, "value1", "value2", ... "valueN")` The preview forms `names(...)` and `values(...)` have implicit meaning that are not strait-forward. In particular `values(foo)`&`values(bar)` and `names(foo, bar)` are not equivalent which has created [some confusions](rust-lang/rust#98080). Also the `names()` and `values()` form are not clear either and again created some confusions where peoples believed that `values()`&`values(foo)` could be reduced to just `values(foo)`. To fix that the two new forms are made to be explicit and simpler. See the table of correspondence: - `names()` -> `exhaustive(names)` - `values()` -> `exhaustive(values)` - `names(foo)` -> `exhaustive(names)`&`configure(foo)` - `values(foo)` -> `configure(foo)` - `values(feat, "foo", "bar")` -> `configure(feat, "foo", "bar")` - `values(foo)`&`values(bar)` -> `configure(foo, bar)` - `names()`&`values()`&`values(my_cfg)` -> `exhaustive(names, values)`&`configure(my_cfg)` Another benefits of the new syntax is that it allow for further options (like conditional checking for --cfg, currently always on) without syntax change. The two previous forms are deprecated and will be removed once cargo and beta rustc have the necessary support. </details> This PR is the first part of the implementation of [MCP636 - Simplify and improve explicitness of the check-cfg syntax](rust-lang/compiler-team#636). ## New `cfg` form It introduces the new [`cfg` form](rust-lang/compiler-team#636) and deprecate the other two: ``` rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))' ``` ## Default built-in names and values It also changes the default for the built-in names and values checking. - Built-in values checking would always be activated as long as a `--check-cfg` argument is present - Built-in names checking would always be activated as long as a `--check-cfg` argument is present **unless** if any `cfg(any())` arg is passed ~~**Note: depends on rust-lang/rust#111068 but is reviewable (last two commits)!**~~ Resolve rust-lang/compiler-team#636 r? `@petrochenkov`
Special case iterator chain checks for suggestion When encountering method call chains of `Iterator`, check for trailing `;` in the body of closures passed into `Iterator::map`, as well as calls to `<T as Clone>::clone` when `T` is a type param and `T: !Clone`. Fix #9082.
Add MonoItems and Instance to stable_mir Also add a few methods to instantiate instances and get an instance definition. We're still missing support to actually monomorphize the instance body. This is related to rust-lang/project-stable-mir#36 r? ``@oli-obk`` ``@oli-obk`` is that what you were thinking? I incorporated ``@bjorn3`` idea of just adding a Shim instance definition in rust-lang/rust#116465.
Implement an internal lint encouraging use of `Span::eq_ctxt` Adds a new Rustc internal lint that forbids use of `.ctxt() == .ctxt()` for spans, encouraging use of `.eq_ctxt()` instead (see rust-lang/rust#49509). Also fixed a few violations of the lint in the Rustc codebase (a fun additional way I could test my code). Edit: MIR opt folks I believe that's why you're CC'ed, just a heads up. Two things I'm not sure about: 1. The way I chose to detect calls to `Span::ctxt`. I know adding diagnostic items to methods is generally discouraged, but after some searching and experimenting I couldn't find anything else that worked, so I went with it. That said, I'm happy to implement something different if there's a better way out there. (For what it's worth, if there is a better way, it might be worth documenting in the rustc-dev-guide, which I'm happy to take care of) 2. The error message for the lint. Ideally it would probably be good to give some context as to why the suggestion is made (e.g. `rustc::default_hash_types` tells the user that it's because of performance), but I don't have that context so I couldn't put it in the error message. Happy to iterate on the error message based on feedback during review. r? ``@oli-obk``
…errors Make `handle_options` public again. r? ``@compiler-errors``
Rollup of 5 pull requests Successful merges: - #111072 (Add new simpler and more explicit syntax for check-cfg) - #116717 (Special case iterator chain checks for suggestion) - #116719 (Add MonoItems and Instance to stable_mir) - #116787 (Implement an internal lint encouraging use of `Span::eq_ctxt`) - #116827 (Make `handle_options` public again.) r? `@ghost` `@rustbot` modify labels: rollup
Normalize alloc-id in tests. AllocIds are globally numbered in a rustc invocation. This makes them very sensitive to changes unrelated to what is being tested. This commit normalizes them by renumbering, in order of appearance in the output. The renumbering allows to keep the identity, that a simple `allocN` wouldn't. This is useful when we have memory dumps. cc `@saethlin` r? `@oli-obk`
Update to LLVM 17.0.3 Fixes rust-lang/rust#116582. Fixes miscompile reported at rust-lang/rust#104862. r? `@cuviper`
Automatically enable cross-crate inlining for small functions This is basically reviving rust-lang/rust#70550 The `#[inline]` attribute can have a significant impact on code generation or runtime performance (because it enables inlining between CGUs where it would normally not happen) and also on compile-time performance (because it enables MIR inlining). But it has to be added manually, which is awkward. This PR factors whether a DefId is cross-crate inlinable into a query, and replaces all uses of `CodegenFnAttrs::requests_inline` with this new query. The new query incorporates all the other logic that is used to determine whether a Def should be treated as cross-crate-inlinable, and as a last step inspects the function's optimized_mir to determine if it should be treated as cross-crate-inlinable. The heuristic implemented here is deliberately conservative; we only infer inlinability for functions whose optimized_mir does not contain any calls or asserts. I plan to study adjusting the cost model later, but for now the compile time implications of this change are so significant that I think this very crude heuristic is well worth landing.
This commit is generated by `ferrocene/tools/pull-upstream/pull.sh`. The list of excluded files is defined in `.gitattributes`.
|
Build succeeded: |
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.
handle_optionspublic again. rust-lang/rust#116827Span::eq_ctxtrust-lang/rust#116787~constbounds with a non-const one in effects desugaring rust-lang/rust#116756