| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Part of #60485
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #112297 (bootstrap: Disallow `--exclude test::std`)
- #112298 (Update field-offset and enable unstable_offset_of)
- #112335 (ci: Upgrade loongarch64-linux-gnu GCC to 13.1.0)
- #112413 (Adjust span labels for `HIDDEN_GLOB_REEXPORTS`)
- #112483 (Add deprecation warning to python versions <3.6 in x.py)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add deprecation warning to python versions <3.6 in x.py
Introduced based on conversation on Zulip. This is a repeat of #110439 with two changes:
- Warning rather than exit
- Can be suppressed via an environment variable
The min to not get the warning is set to 3.6 because that's a fairly recent "old" version (went EOL in 2021) and it's the first version to support useful modern features like f-strings and type hints.
cc `@Nilstrieb` (author of #110439) and `@Mark-Simulacrum` (reviewer of that PR)
|
|
r=petrochenkov
Adjust span labels for `HIDDEN_GLOB_REEXPORTS`
Addresses https://github.com/rust-lang/rust/pull/111378#issuecomment-1581226063.
### Before This PR
The possibility that the private item comes before the glob re-export was not account for, causing the span label messages to say "but private item here shadows it" before "the name `Foo` in the type namespace is supposed to be publicly re-exported here".
### After This PR
```rust
warning: private item shadows public glob re-export
--> $DIR/hidden_glob_reexports.rs:9:5
|
LL | struct Foo;
| ^^^^^^^^^^^ the private item here shadows the name `Foo` in the type namespace
...
LL | pub use self::inner::*;
| -------------- but it is supposed to be publicly re-exported here
|
= note: `#[warn(hidden_glob_reexports)]` on by default
warning: private item shadows public glob re-export
--> $DIR/hidden_glob_reexports.rs:27:9
|
LL | pub use self::inner::*;
| -------------- the name `Foo` in the type namespace is supposed to be publicly re-exported here
LL |
LL | use self::other::Foo;
| ^^^^^^^^^^^^^^^^ but the private item here shadows it
```
|
|
ci: Upgrade loongarch64-linux-gnu GCC to 13.1.0
This PR upgrades GCC to 13.1.0 for the `loongarch64-unknown-linux-gnu` target. This upgrade was suggested in a previous review discussion: https://github.com/rust-lang/rust/pull/110519#discussion_r1184613749
|
|
Update field-offset and enable unstable_offset_of
This makes the compiler use the builtin `offset_of!()` macro, through the wrappers in memoffset and then in field-offset.
cc #111839
|
|
bootstrap: Disallow `--exclude test::std`
Use the top-level Kind to determine whether Steps are excluded.
Previously, this would use the `Kind` passed to `--exclude` (and not do any filtering at all if no kind was passed).
That meant that `x test linkchecker --exclude std` would fail - you had to explicitly say `--exclude test::std`.
Change bootstrap to use the top-level Kind instead, which does the right thing automatically.
Note that this breaks things like `x test --exclude doc::std`, but I'm not sure why you'd ever want to do that.
There's a lot of churn here, but the 1-line change in the first commit is the actual behavior change, the rest is just cleanup.
Fixes https://github.com/rust-lang/rust/issues/103201. Note that this effectively reverts most of https://github.com/rust-lang/rust/pull/91965.
cc `@pietroalbini`
|
|
Uplift `clippy::cmp_nan` lint
This PR aims at uplifting the `clippy::cmp_nan` lint into rustc.
## `invalid_nan_comparisons`
~~(deny-by-default)~~ (warn-by-default)
The `invalid_nan_comparisons` lint checks comparison with `f32::NAN` or `f64::NAN` as one of the operand.
### Example
```rust,compile_fail
let a = 2.3f32;
if a == f32::NAN {}
```
### Explanation
NaN does not compare meaningfully to anything – not even itself – so those comparisons are always false.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
Rollup of 6 pull requests
Successful merges:
- #110141 (expand: Change how `#![cfg(FALSE)]` behaves on crate root)
- #112369 (More CGU cleanups)
- #112467 (Compile rustc_driver by default)
- #112468 (Change format of rustdoc-js tests by putting query and correction directly alongside the expected values)
- #112473 (Update cargo)
- #112481 (Ignore tests that hang in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Ignore tests that hang in new solver
This makes it easier to run `--compare-mode=next-solver`, and we can revisit these tests later to find out how to make them less overflowy 😅
r? `@lcnr`
|
|
Update cargo
12 commits in b0fa79679e717cd077b7fc0fa4166f47107f1ba9..49b6d9e179a91cf7645142541c9563443f64bf2b
2023-06-03 14:19:48 +0000 to 2023-06-09 17:21:19 +0000
- docs: doc comments for all registry kinds (rust-lang/cargo#12247)
- chore: Migrate print-ban from test to clippy (rust-lang/cargo#12246)
- fix: fetch nested git submodules (rust-lang/cargo#12244)
- refactor: registry source cleanup (rust-lang/cargo#12240)
- test: loose overly matches for git cli output (rust-lang/cargo#12241)
- fix: disable multiplexing on macOS for some versions of curl (rust-lang/cargo#12234)
- docs: doc comments for registry source and index (rust-lang/cargo#12239)
- doc: point to nightly cargo doc (rust-lang/cargo#12237)
- Upgrade to `gix` v0.45 for multi-round pack negotiations. (rust-lang/cargo#12236)
- refactor: git source cleanup (rust-lang/cargo#12197)
- Add message on reusing previous temporary path on failed cargo installs (rust-lang/cargo#12231)
- doc: the first line should be a simple sentence instead of a heading (rust-lang/cargo#12228)
r? `@ghost`
|
|
Change format of rustdoc-js tests by putting query and correction directly alongside the expected values
As I was working on fixing merge conflicts in #108537, I faced quite a big issue when trying to update the `rustdoc-js*` tests. To make it much simpler, this PR moves the `query` and `correction` directly alongside the expected data so now we know what is the query that is being run without needing to add comments or going back to the top of the file.
r? ```@notriddle```
|
|
Compile rustc_driver by default
Fixes #112440. It now properly compiles `rustc_driver` and opens the doc page.
|
|
More CGU cleanups
An assortment of improvements.
r? `@wesleywiser`
|
|
expand: Change how `#![cfg(FALSE)]` behaves on crate root
Previously it removed all other attributes from the crate root.
Now it removes only attributes below itself (during both regular expansion and pre-configuration).
So it becomes possible to configure some global crate properties even for fully unconfigured crates.
Fixes https://github.com/rust-lang/rust/issues/104633
Part of https://github.com/rust-lang/rust/issues/110082
|
|
|
|
|
|
|
|
Make "consider importing" consistent for macros
Fixes #112439
|
|
Soft deprecate old python versions to give users a warning that
eventually it may not be supported.
|
|
increase the accuracy of effective visibilities calculation
Effective visibilities are calculated lazily due to performance restrictions. Therefore
- crate should be walked at least 1 time in `compute_effective_visibilities` pass
- Impl's should always be in the effective visibilities table
to ensure that the table is filled in correctly.
r? `@petrochenkov`
|
|
|
|
Previously it removed all other attributes from the crate root.
Now it removes only attributes below itself.
So it becomes possible to configure some global crate properties even for fully unconfigured crates.
|
|
|
|
Support float-like tuple indices in offset_of!()
Supports invocations like `offset_of!((((), ()), ()), 0.0)`. This `0.0` gets tokenized as float literal, so it has to be broken up again.
The code that did the breaking up was returning a finished `Expr`, while we need a `Ident`, so this PR splits up the `parse_expr_tuple_field_access_float` function into:
* a function that breaks up the float literal (similar to `TokenKind::break_two_token_op`, but we do access the parser during this splitting operation, so we keep it as an inherent function on the parser)
* and a function that constructs an `Expr` from it
The former we can then re-use in `offset_of` parsing. The edge cases especially involving whitespaces are tricky so this adds a bunch of new tests as well.
fixes #112204
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #112260 (Improve document of `unsafe_code` lint)
- #112429 ([rustdoc] List matching impls on type aliases)
- #112442 (Deduplicate identical region constraints in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
directly alongside the expected values
|
|
|
|
compiler-errors:next-solver-deduplicate-region-constraints, r=lcnr
Deduplicate identical region constraints in new solver
the new solver doesn't track whether we've already proven a goal like the fulfillment context's obligation forest does, so we may be instantiating a canonical response (and specifically, its nested region obligations) quite a few times.
This may lead to exponentially gathering up identical region constraints for things like auto traits, so let's deduplicate region constraints when in `compute_external_query_constraints`.
r? ``@lcnr``
|
|
[rustdoc] List matching impls on type aliases
Fixes #32077.
Thanks a lot to ``@lcnr`` who helped me a lot with this fix!
cc ``@notriddle``
r? ``@lcnr``
|
|
Improve document of `unsafe_code` lint
This PR add another `unsafe_code` lint example, want to close #111967
|
|
Uplift `clippy::undropped_manually_drops` lint
This PR aims at uplifting the `clippy::undropped_manually_drops` lint.
## `undropped_manually_drops`
(warn-by-default)
The `undropped_manually_drops` lint check for calls to `std::mem::drop` with a value of `std::mem::ManuallyDrop` which doesn't drop.
### Example
```rust
struct S;
drop(std::mem::ManuallyDrop::new(S));
```
### Explanation
`ManuallyDrop` does not drop it's inner value so calling `std::mem::drop` will not drop the inner value of the `ManuallyDrop` either.
-----
Mostly followed the instructions for uplifting an clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::undropped_manually_drops` into rustc
|
|
Signed-off-by: Eval EXEC <execvy@gmail.com>
|
|
Write to stdout if `-` is given as output file
With this PR, if `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (those of type `obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together.
This implements https://github.com/rust-lang/compiler-team/issues/431
The idea behind the changes is to introduce an `OutFileName` enum that represents the output - be it a real path or stdout - and to use this enum along the code paths that handle different output types.
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #112323 (Don't mention already-set fields in struct constructor missing field error)
- #112395 (Add Terminator::InlineAsm conversion from MIR to SMIR)
- #112411 (add programmerjake to portable-simd cc list)
- #112428 (Structurally resolve pointee in `check_pat_lit`)
- #112444 (Don't debug-print `Interned` or `PrivateZst`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't debug-print `Interned` or `PrivateZst`
Instead of, e.g.
`PredefinedOpaques(Interned(PredefinedOpaquesData { ... }, PrivateZst))`
print:
`PredefinedOpaques(PredefinedOpaquesData { ... })`
Mostly observable in debug logs, or ICE backtraces where I saw this.
r? ``@nnethercote``
|
|
Structurally resolve pointee in `check_pat_lit`
Gotta make sure to eager norm the pointee of the match scrutinee with the new solver.
r? ``@lcnr``
|
|
add programmerjake to portable-simd cc list
|
|
Add Terminator::InlineAsm conversion from MIR to SMIR
This is the last variant that needed to be covered for Terminator. As we've discussed with ``@oli-obk`` I've made a lot of it's fields be `String`s.
r? ``@oli-obk``
|
|
r=WaffleLapkin
Don't mention already-set fields in struct constructor missing field error
Fixes #111149
|
|
r=WaffleLapkin
Misc HIR typeck type mismatch tweaks
These are all intended to improve #112104, but I couldn't get it to actually suggest adding `as_ref` to the LHS of the equality expr without some hacks that I may play around with some more.
Each commit's title should explain what it's doing except for perhaps the last one, which addresses the bogus suggestion on #112104 itself.
|
|
|
|
Take MIR dataflow analyses by mutable reference
The main motivation here is any analysis requiring dynamically sized scratch memory to work. One concrete example would be pointer target tracking, where tracking the results of a dereference can result in multiple possible targets. This leads to processing multi-level dereferences requiring the ability to handle a changing number of potential targets per step. A (simplified) function for this would be `fn apply_deref(potential_targets: &mut Vec<Target>)` which would use the scratch space contained in the analysis to send arguments and receive the results.
The alternative to this would be to wrap everything in a `RefCell`, which is what `MaybeRequiresStorage` currently does. This comes with a small perf cost and loses the compiler's guarantee that we don't try to take multiple borrows at the same time.
For the implementation:
* `AnalysisResults` is an unfortunate requirement to avoid an unconstrained type parameter error.
* `CloneAnalysis` could just be `Clone` instead, but that would result in more work than is required to have multiple cursors over the same result set.
* `ResultsVisitor` now takes the results type on in each function as there's no other way to have access to the analysis without cloning it. This could use an associated type rather than a type parameter, but the current approach makes it easier to not care about the type when it's not necessary.
* `MaybeRequiresStorage` now no longer uses a `RefCell`, but the graphviz formatter now does. It could be removed, but that would require even more changes and doesn't really seem necessary.
|
