-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 5 pull requests #116855
Rollup of 5 pull requests #116855
Conversation
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 rust-lang#9082.
Also add a few methods to instantiate instances and get an instance definition. We're still missing support to actually monomorphize the instance body.
…ochenkov 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#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#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 rust-lang#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#116465.
…li-obk 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#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``
…compiler-errors Make `handle_options` public again. r? ``@compiler-errors``
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: bb74d1fa85 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (94ba57c): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 627.198s -> 627.092s (-0.02%) |
57: Pull upstream master 2023 10 18 r=pietroalbini a=Veykril * rust-lang/rust#116505 * rust-lang/rust#116840 * rust-lang/rust#116767 * rust-lang/rust#116855 * rust-lang/rust#116827 * rust-lang/rust#116787 * rust-lang/rust#116719 * rust-lang/rust#116717 * rust-lang/rust#111072 * rust-lang/rust#116844 * rust-lang/rust#115577 * rust-lang/rust#116756 * rust-lang/rust#116518 Co-authored-by: Urgau <[email protected]> Co-authored-by: Esteban Küber <[email protected]> Co-authored-by: Deadbeef <[email protected]> Co-authored-by: Ralf Jung <[email protected]> Co-authored-by: Camille GILLOT <[email protected]> Co-authored-by: Celina G. Val <[email protected]> Co-authored-by: Nicholas Nethercote <[email protected]> Co-authored-by: Arthur Lafrance <[email protected]> Co-authored-by: Nikolay Arhipov <[email protected]> Co-authored-by: Nikita Popov <[email protected]> Co-authored-by: bors <[email protected]>
Successful merges:
Span::eq_ctxt
#116787 (Implement an internal lint encouraging use ofSpan::eq_ctxt
)handle_options
public again. #116827 (Makehandle_options
public again.)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup