Fix `tidy --bless` on ̶X̶e̶n̶i̶x̶ Windows
As reported in https://github.com/rust-lang/rust/pull/120628#issuecomment-1973655740 the requested `tidy --bless` implementation didn't take into account the fact that earlier the linting code canonicalized things to use the OS path separator. This makes it so that the path separator is always rewritten back as '/', which should fix the variance there.
r? ``@ChrisDenton``
Don't require specifying unrelated assoc types when trait alias is in `dyn` type
Object types must specify the associated types for all of the principal trait ref's supertraits. However, we weren't doing elaboration properly, so we incorrectly errored with erroneous suggestions to specify associated types that were unrelated to that principal trait ref. To fix this, use proper supertrait elaboration when expanding trait aliases in `conv_object_ty_poly_trait_ref`.
**NOTE**: Please use the ignore-whitespace option when reviewing. This only touches a handful of lines.
r? oli-obk or please feel free to reassign.
Fixes#122118
Make not finding core a fatal error
Similar to https://github.com/rust-lang/rust/pull/120472, this prevents terminal spam. In particular, it makes the good diagnostic visible when you try to use a target that's not installed.
Apply `EarlyBinder` only to `TraitRef` in `ImplTraitHeader`
Resolves#121852
This PR
1. Moves `EarlyBinder` to `TraitRef` inside `ImplTraitHeader`,
2. Changes visibility of `coherence::builtin::check_trait` to `pub(super)` from `pub` as it seems not being re-exported from the `coherence` module.
silence mismatched types errors for implied projections
Currently, if a trait bound is not satisfied, then we suppress any errors for the trait's supertraits not being satisfied, but still report errors for super projections not being satisfied.
For example:
```rust
trait Super {
type Assoc;
}
trait Sub: Super<Assoc = ()> {}
```
Before this PR, if `T: Sub` is not satisfied, then errors for `T: Super` are suppressed, but errors for `<T as Super>::Assoc == ()` are still shown. This PR makes it so that errors about super projections not being satisfied are also suppressed.
The errors are only suppressed if the span of the trait obligation matches the span of the super predicate obligation to avoid silencing error that are not related. This PR removes some differences between the spans of supertraits and super projections to make the suppression work correctly.
This PR fixes the majority of the diagnostics fallout when making `Thin` a supertrait of `Sized` (in a future PR).
cc https://github.com/rust-lang/rust/pull/120354#issuecomment-1930585382
cc `@lcnr`
Merge `check_mod_impl_wf` and `check_mod_type_wf`
This still causes some funny diagnostics, but I'm not sure they can be fixed without a larger change, which I'd like to avoid here.
Reducing the number of times we iterate over the same items at this high level helps avoid parallel-compiler bottlenecks.
Update cargo
14 commits in f772ec0224d3755ce52ac5128a80319fb2eb45d0..a4c63fe5388beaa09e5f91196c86addab0a03580
2024-03-01 22:57:35 +0000 to 2024-03-06 22:15:17 +0000
- fix(cli): Skip tracing-chrome for platforms without 64bit atomics (rust-lang/cargo#13551)
- chore: downgrade to openssl v1.1.1 (again) (rust-lang/cargo#13550)
- fix(cli): Add traces to clarify where time is going (rust-lang/cargo#13545)
- fix(rustdoc-map): dedup `--extern-html-too-url` for same unit (rust-lang/cargo#13544)
- test: Add test for packaging a public dependency (rust-lang/cargo#13536)
- doc: Edits for git/path dependency sections (rust-lang/cargo#13341)
- feat(cli): Allow logging to chrome traces (rust-lang/cargo#13399)
- fix(log): Trace parameters to align with profile (rust-lang/cargo#13538)
- fix(toml): Don't warn on unset Edition if only 2015 is compatible (rust-lang/cargo#13533)
- fix(cli): Trace core cargo operations (rust-lang/cargo#13532)
- chore: update pulldown-cmark to 0.10.0 (rust-lang/cargo#13517)
- feat(add): Fallback to `rustc -v` when no MSRV is set (rust-lang/cargo#13516)
- chore(ci): Ensure lockfile is respected during MSRV testing (rust-lang/cargo#13523)
- feat: Use consistent colors when testing (rust-lang/cargo#13520)
Rollup of 9 pull requests
Successful merges:
- #121958 (Fix redundant import errors for preload extern crate)
- #121976 (Add an option to have an external download/bootstrap cache)
- #122022 (loongarch: add frecipe and relax target feature)
- #122026 (Do not try to format removed files)
- #122027 (Uplift some feeding out of `associated_type_for_impl_trait_in_impl` and into queries)
- #122063 (Make the lowering of `thir::ExprKind::If` easier to follow)
- #122074 (Add missing PartialOrd trait implementation doc for array)
- #122082 (remove outdated fixme comment)
- #122091 (Note why we're using a new thread in `test_get_os_named_thread`)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Add a `//@ needs-threads` directive
This commit is extracted from #122036 and adds a new directive to the `compiletest` test runner, `//@ needs-threads`. This is intended to capture the need that a target must implement threading to execute a specific test, typically one that uses `std::thread`. This is primarily done for WebAssembly targets which currently do not have threads by default. This enables transitioning a lot of `//@ ignore-wasm*`-style ignores into a more self-documenting `//@ needs-threads` directive. Additionally the `wasm32-wasi-preview1-threads` target, for example, does actually have threads, but isn't tested in CI at this time. This change enables running these tests for that target, but not other wasm targets.
Remove unnecessary fixme on new thread stack size
As the FIXME itself notes, there's nothing to fix here.
And as the documentation for [`CreateThread`] says of `dwStackSize`, the value is rounded up to the nearest page. A 4kb stack is very small but perfectly usable if you're careful. Of course it will be very limited but there's no reason to add artificial limits. We don't know what the user is doing.
[`CreateThread`]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread
Refer to "slice" instead of "vector" in Ord and PartialOrd trait impl of slices
The trait implementation comments of Ord and PartialOrd for slice incorrectly mention "vectors" instead of "slices".
This PR fixes those two comments as requested in #122071.
Explicitly assign constructed C++ classes
C++ style guides I am aware of recommend specifically preferring = syntax for any classes with fairly obvious constructors[^0] that do not perform any complicated logic in their constructor. I contend that all constructors that the `rustc_llvm` code uses qualify. This has only become more common since C++ 17 guaranteed many cases of copy initialization elision.
The other detail is that I tried to ask another contributor with infinitely more C++ experience than me (i.e. any) what this constructor syntax was, and they thought it was a macro. I know of no other language that has adopted this same syntax. As the rustc codebase features many contributors experienced in many other languages, using a less... unique... style has many other benefits in making this code more lucid and maintainable, which is something it direly needs.
[^0]: e.g. https://abseil.io/tips/88
Add better explanation for `rustc_index::IndexVec`
I feel like I didn't do a great job explaining what this does in https://github.com/rust-lang/rust/pull/119800, so this PR tries to give an example of why and how you would use it.
Addresses #93792.
Note why we're using a new thread in `test_get_os_named_thread`
``@RalfJung`` expressed some "surprise and confusion" about why we're spawning a new thread in this test. Hopefully this comment will help future readers.
remove outdated fixme comment
The `TraitPredicate` no longer has constness as we have desugared it to work with the type system through const generics instead.
Add missing PartialOrd trait implementation doc for array
Analogously to vectors and slices, this PR documents the lexicographic sorting of PartialOrd as rustdoc comment on the trait implementation of PartialOrd for arrays.
Associated issue: #122073.
Make the lowering of `thir::ExprKind::If` easier to follow
This targets a few code patterns that I found very confusing when I first tried to understand what this code is doing.
No functional changes. I recommend looking at the changes individually, with whitespace hidden.
Uplift some feeding out of `associated_type_for_impl_trait_in_impl` and into queries
This PR moves the `type_of` and `generics_of` query feeding out of `associated_type_for_impl_trait_in_impl`, since eagerly feeding results in query cycles due to a subtle interaction with `resolve_bound_vars`.
Fixes#122019
r? spastorino
Do not try to format removed files
If you removed a file, `x fmt` would confusingly print
```
formatting modified file path/to/file.rs
```
and pass it to the formatting logic. Filter out files with `D` (removed) status
loongarch: add frecipe and relax target feature
This PR adds `frecipe` and `relax` target features to LoongArch:
* frecipe - Support frecipe.{s/d} and frsqrte.{s/d} instructions..
* relax - Enable Linker relaxation.
cleanup: remove zero-offset GEP
This GEP would've been used to change the pointer type in the past, but after opaque pointers it's a no-op. I missed removing this in #105545.
Split out from #121577.
Fix linting paths with qself in `unused_qualifications`
Fixes#121999
`resolve_qpath` ends up being called again with `qself` set to `None` to check trait items from fully qualified paths. To avoid this the lint is moved to a place that accounts for this already
96561a8fd1/compiler/rustc_resolve/src/late.rs (L4074-L4088)
r? `````@petrochenkov`````
Removing absolute path in proc-macro
With rust 1.75 the absolute build path name is embedding into proc-macro (.rustc section) and which causes reproducibility issues.
Detailed issue description is here - https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
With this change the 'absolute path' changed back to '/rust/$hash' format as in earlier revisions.
Rework `untranslatable_diagnostic` lint
Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`.
r? ``@davidtwco``
avoid overlapping privacy suggestion for single nested imports
Fixes#114884
This PR aims to avoid confusion inside braces for import suggestions.
r? ``@petrochenkov``
