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``
Change the documented implicit value of `-C instrument-coverage` to `=yes`
The option-value parser for `-Cinstrument-coverage=` currently accepts the following stable values:
- `all` (implicit value of plain `-Cinstrument-coverage`)
- `yes`, `y`, `on`, `true` (undocumented aliases for `all`)
- `off` (default; same as not specifying `-Cinstrument-coverage`)
- `no`, `n`, `false`, `0` (undocumented aliases for `off`)
I'd like to rearrange and re-document the stable values as follows:
- `no` (default; same as not specifying `-Cinstrument-coverage`)
- `n`, `off`, `false` (documented aliases for `no`)
- `0` (undocumented alias for `no`)
- `yes` (implicit value of plain `-Cinstrument-coverage`)
- `y`, `on`, `true` (documented aliases for `yes`)
- `all` (documented as *currently* an alias for `yes` that may change; discouraged but not deprecated)
The main changes being:
- Documented default value changes from `off` to `no`
- Documented implicit value changes from `all` to `yes`
- Other boolean aliases (`n`, `off`, `false`, `y`, `on`, `true`) are explicitly documented
- `all` remains currently an alias for `yes`, but is explicitly documented as being able to change in the future
- `0` remains an undocumented but stable alias for `no`
- The actual behaviour of coverage instrumentation does not change
# Why?
The choice of `all` as the implicit value only really makes sense in the context of the unstable `except-unused-functions` and `except-unused-generics` values. That arrangement was fine for an unstable flag, but it's confusing for a stable flag whose only other stable value is `off`, and will only become more confusing if we eventually want to stabilize other fine-grained coverage option values.
(Currently I'm not aware of any plans to stabilize other coverage option values, but that's why I think now is a fine time to make this change, well before anyone actually has to care about it.)
For example, if we ever add support for opt-in instrumentation of things that are *not* instrumented by `-Cinstrument-coverage` by default, it will be very strange for the `all` value to not actually instrument all things that we know how to instrument.
# Compatibility impact
Because this is not a functional change, there is no immediate compatibility impact. However, changing the documented semantics of `all` opens up the possibility of future changes that could be considered retroactively breaking.
I don't think this is going to be a big deal in practice, for a few reasons:
- The exact behaviour of coverage instrumentation is allowed to change, so changing the behaviour of `all` is not a *stability-breaking* change, as long as it still exists and does something reasonable.
- `-Cinstrument-coverage` is mainly used by tools or scripts that can be easily updated if necessary. It's unusual for users to pass the flag directly, because processing the profiler output is complicated enough that tools/scripts tend to be necessary anyway.
- Most people who are using coverage are probably relying on `-Cinstrument-coverage` rather than explicitly passing `-Cinstrument-coverage=all`, so the number of users actually affected by this change is likely to be low, and plausibly zero.
bootstrap/libtest: print test name eagerly on failure even with `verbose-tests=false` / `--quiet`
Previously, libtest would wait until all tests finished running to print the progress, which made it
annoying to run many tests at once (since you don't know which have failed). Change it to print the
names as soon as they fail.
This makes it much easier to know which test failed without having to wait for compiletest to completely finish running. Before:
```
Testing stage0 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu)
running 15274 tests
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 88/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 176/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 264/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 352/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 440/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 528/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiFFiiiiiii
...
```
After:
```
Testing stage0 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu)
running 15274 tests
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 88/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 176/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 264/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 352/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 440/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 528/15274
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
[ui] tests/ui/associated-type-bounds/implied-in-supertrait.rs ... F
[ui] tests/ui/associated-type-bounds/return-type-notation/basic.rs#next_with ... F
iiiiiiiiiiiii
...
```
This serves a similar use case to the existing RUSTC_TEST_FAIL_FAST, but is on by default and as a result much more discoverable. We should consider unifying RUSTC_TEST_FAIL_FAST with the `--no-fail-fast` flag in the future for consistency and discoverability.
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.
This commit adds the said relation by keeping a map of type `FxHashMap<SourceRootId,Option<SourceRootId>>`
inside the `GlobalState`. Its primary use case is reading the rust-analyzer.toml files that can be
placed under every local source root. As a config will be found by traversing this "tree" we need the parent information
for every local source root. This commit omits defining this relation for library source roots entirely.
On modern Linux with Intel AMX and 1KiB matrices,
Arm SVE with potentially 2KiB vectors,
and RISCV Vectors with up to 16KiB vectors,
we must handle dynamic signal stack sizes.
We can do so unconditionally by using getauxval,
but assuming it may return 0 as an answer,
thus falling back to the old constant if needed.
fix: panic when using float numbers without dots in chain calls
Fix#16278.
This PR fixes the panic caused by using floating-point numbers without a dot (such as `1e2`) in chain calls.
-------------
Although this syntax is very odd 🤣, r-a should not panic.
