Bump black, ruff and platformdirs
Mainly because I encountered the following error, and we have no reason to prevent our upgrade.
```
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed.
This behaviour is the source of the following dependency conflicts.
virtualenv 20.25.3 requires platformdirs<5,>=3.9.1, but you have platformdirs 3.6.0 which is incompatible.
```
r? `@Kobzol`
miri: make sure we can find link_section statics even for the local crate
Miri needs some way to iterate all the exported functions and "used" statics of all crates. For dependency crates, this already works fine since we can overwrite the query resonsible for computing `exported_symbols`, but it turns out for local binary crates this does not work: for binaries, `reachable_set` skips a lot of its logic and only checks `contains_extern_indicator()` and `RUSTC_STD_INTERNAL_SYMBOL`. Other flags like `CodegenFnAttrFlags::USED` are entirely ignored.
This PR proposes to use the same check, `has_custom_linkage`, in binaries that we already use to drive the main workqueue of the reachability recursive traversal. I have no idea why binaries used a slightly different check that ignores `USED` -- was that deliberate or does it just not matter most of the time?
Update cargo
10 commits in bc89bffa5987d4af8f71011c7557119b39e44a65..4ed7bee47f7dd4416b36fada1909e9a62c546246
2024-06-22 00:36:36 +0000 to 2024-06-25 16:28:22 +0000
- test: omit target-dir name (rust-lang/cargo#14142)
- test: migrate offline, open_namespaces and owner to snapbox (rust-lang/cargo#14138)
- docs: remove stray comment (rust-lang/cargo#14133)
- Change tests to support `rustc` wording changes (rust-lang/cargo#14135)
- deps: dont use tracing-attributes for workspace, use for cargo only (rust-lang/cargo#14122)
- Include vcs_info even if workspace is dirty (rust-lang/cargo#13960)
- test: migrate profile* to snapbox (rust-lang/cargo#14128)
- test: migrate path and paths to snapbox (rust-lang/cargo#14109)
- test: migrate rustflags, rustup and script to snapbox (rust-lang/cargo#14126)
- test: migrate rename_deps, replace, required_features and run to snapbox (rust-lang/cargo#14127)
Mainly because I encountered the following error, and we have no reason to prevent our upgrade.
```
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed.
This behaviour is the source of the following dependency conflicts.
virtualenv 20.25.3 requires platformdirs<5,>=3.9.1, but you have platformdirs 3.6.0 which is incompatible.
```
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level
I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer).
As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals).
There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another.
d49994b060/compiler/rustc_ast/src/util/parser.rs (L236-L237)d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L2829)d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L1290)
In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1.
There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax — you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level.
d49994b060/compiler/rustc_ast_pretty/src/pprust/state/expr.rs (L217-L221)
ast: Standardize visiting order for attributes and node IDs
This should only affect `macro_rules` scopes and order of diagnostics.
Also add a deprecation lint for `macro_rules` called outside of their scope, like in https://github.com/rust-lang/rust/issues/124535.
Add `SliceLike` to `rustc_type_ir`, use it in the generic solver code (+ some other changes)
First, we split out `TraitRef::new_from_args` which takes *just* `ty::GenericArgsRef` from `TraitRef::new` which takes `impl IntoIterator<Item: Into<GenericArg>>`. I will explain in a minute why.
Second, we introduce `SliceLike`, which allows us to be generic over `List<T>` and `[T]`. This trait has an `as_slice()` and `into_iter()` method, and some other convenience functions. However, importantly, since types like `I::GenericArgs` now implement `SliceLike` rather than `IntoIter<Item = I::GenericArg>`, we can't use `TraitRef::new` on this directly. That's where `new_from_args` comes in.
Finally, we adjust all the code to use these slice operators. Some things get simpler, some things get a bit more annoying since we need to use `as_slice()` in a few places. 🤷
r? lcnr
std: refactor the TLS implementation
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
`@rustbot` label +A-thread-locals
Remove stray println from rustfmt's `rewrite_static`
r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong.
This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this.
Fix https://github.com/rust-lang/rustfmt/issues/6210
Fix https://github.com/rust-lang/rust/issues/126887
Implement `use<>` formatting in rustfmt
This PR implements formatting for precise-capturing `use<>` syntax as proposed in https://github.com/rust-lang/rust/pull/126753.
The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier.
I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If ``@rust-lang/rustfmt`` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive.
This implementation is otherwise rather straightforward.
Tracking:
- https://github.com/rust-lang/rust/issues/123432
Add needs-symlink directive to compiletest
This is an alternative to #126846 that allows running symlink tests on Windows in CI but will ignore them locally if symlinks aren't available. A future improvement would be to check that the `needs-symlink` directive is used in rmake files that call `create_symlink` but this is just a quick PR to unblock Windows users who want to run tests locally without enabling symlinks.
Rework pattern and expression nonterminal kinds.
Some tweaks to `NonterminalKind` that will assist with #124141. Details in the individual commits.
r? compiler-errors
cc ```@eholk```
tidy: skip submodules if not present for non-CI environments
Right now tidy requires rustc-perf to be fetched as it checks its license, but this doesn't make sense for most contributors since rustc-perf is a dist-specific tool and its license will not change frequently, especially during compiler development. This PR makes tidy to skip rustc-perf if it's not fetched and if it's not running in CI.
Applies https://github.com/rust-lang/rust/pull/126225#issuecomment-2158143674 and reverts #126225.
