Teach tidy about line/col information for malformed features
This makes it significantly easier to find the specific feature, since you can now just click it in the command line of your IDE
Fix overflow check
Make MIRI choose the path randomly and rename the intrinsic
Add back test
Add miri test and make it operate on `ptr`
Define `llvm.is.constant` for primitives
Update MIRI comment and fix test in stage2
Add const eval test
Clarify that both branches must have the same side effects
guaranteed non guarantee
use immediate type instead
Co-Authored-By: Ralf Jung <post@ralfj.de>
Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.
The advantage of this is that it does not need to be assigned to a variable to be used in a `Context` creation, which is the most common thing to want to do with a noop waker. It also avoids unnecessarily executing the dynamically dispatched drop function when the noop waker is dropped.
If an owned noop waker is desired, it can be created by cloning, but the reverse is harder to do since it requires declaring a constant. Alternatively, both versions could be provided, like `futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but that seems to me to be API clutter for a very small benefit, whereas having the `&'static` reference available is a large reduction in boilerplate.
[Previous discussion on the tracking issue starting here](https://github.com/rust-lang/rust/issues/98286#issuecomment-1862159766)
Rollup of 10 pull requests
Successful merges:
- #118665 (Consolidate all associated items on the NonZero integer types into a single impl block per type)
- #118798 (Use AtomicU8 instead of AtomicUsize in backtrace.rs)
- #119062 (Deny braced macro invocations in let-else)
- #119138 (Docs: Use non-SeqCst in module example of atomics)
- #119907 (Update `fn()` trait implementation docs)
- #120083 (Warn when not having a profiler runtime means that coverage tests won't be run/blessed)
- #120107 (dead_code treats #[repr(transparent)] the same as #[repr(C)])
- #120110 (Update documentation for Vec::into_boxed_slice to be more clear about excess capacity)
- #120113 (Remove myself from review rotation)
- #120118 (Fix typo in documentation in base.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
dead_code treats #[repr(transparent)] the same as #[repr(C)]
In #92972 we enabled linting on unused fields in tuple structs. In #118297 that lint was enabled by default. That exposed issues like #119659, where the fields of a struct marked `#[repr(transparent)]` were reported by the `dead_code` lint. The language team [decided](https://github.com/rust-lang/rust/issues/119659#issuecomment-1885172045) that the lint should treat `repr(transparent)` the same as `#[repr(C)]`.
Fixes#119659
Warn when not having a profiler runtime means that coverage tests won't be run/blessed
On a few occasions (e.g. #118036, #119984) people have been tripped up by the fact that half of the coverage test suite is skipped by default, because it `// needs-profiler-support` and the profiler runtime is not actually built in any of the default config profiles.
(This is made worse by the fact that it isn't enabled in any of the PR CI jobs either. So people think that they've successfully blessed the test suite, and then get a rude surprise when their merge only fails in the full CI job suite.)
This PR adds a simple warning to compiletest that should alert the user in some cases. It's not foolproof, but it should increase the chances of catching this problem earlier in the PR process.
bootstrap: handle vendored sources when remapping crate paths
#115872 introduced a feature to add path remapping for crate dependencies, but only when they came from Cargo's registry cache, not a vendor directory.
This caused builds that used remapped debuginfo and vendor directories to fail with:
```
std::fs::read_dir(registry_src) failed with No such file or directory (os error 2)
```
or (if the `registry/src` directory exists but is empty)
```
error: --remap-path-prefix must contain '=' between FROM and TO
```
Fixes#117885 by explicitly supporting the `vendor` directory and adding it to `RUSTC_CARGO_REGISTRY_SRC_TO_REMAP`.
Note that `bootstrap.py` already assumes that `./vendor` within the rust repo is the only supported vendoring location.
r? `@pietroalbini`
Don't skip the inconsistent data layout check for custom LLVMs.
With #118708, all targets will have a simple test that would trigger this
check if LLVM's data layouts do change - so data layouts would be
corrected during the LLVM upgrade. Therefore, with builtin targets, this
check won't trigger with our LLVM because each target will have been
confirmed to work. With non-builtin targets, this check is probably
useful to have because you can change the data layout in your target and
if its wrong then that could lead to bugs.
When using a custom LLVM, the same justification makes sense for
non-builtin targets as with our LLVM, the user can update their target to
match their LLVM and that's probably a good thing to do. However, with
a custom LLVM, the user cannot change the builtin target data layouts if
they don't match - though given that the compiler's data layout is used
for layout computation and a bunch of other things - you could get some
bugs because of the mismatch and probably want to know about that.
`CFG_LLVM_ROOT` was also always set during local development with
`download-ci-llvm` so this bug would never trigger locally.
Signed-off-by: David Wood <david@davidtw.co>
Move async closure parameters into the resultant closure's future eagerly
Move async closure parameters into the closure's resultant future eagerly.
Before, we used to desugar `async |p1, p2, ..| { body }` as `|p1, p2, ..| { || async { body } }`. Now, we desugar the above like `|p1, p2, ..| { async move { let p1 = p1; let p2 = p2; ... body } }`. This mirrors the same desugaring that `async fn` does with its parameter types, and the compiler literally uses the same code via a shared helper function.
This removes the necessity for E0708, since now expressions like `async |x: i32| { x }` will not give you confusing borrow errors.
This does *not* fix the case where async closures have self-borrows. This will come with a general implementation of async closures, which is still in the works.
r? oli-obk
Detect `NulInCStr` error earlier.
By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars.
NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together.
One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error.
r? ```@fee1-dead```
By "actual" we refer to the uplifting logic where we may not compile the requested stage;
instead, we uplift it from the previous stages. Which can lead to bootstrap failures in
specific situations where we request stage X from other steps. However we may end up
uplifting it from stage Y, causing the other stage to fail when attempting to link with
stage X which was never actually built.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Update cargo
2 commits in 1cff2ee6b92e0ad3f87c44b70b28f788b2528b3c..1ae631085f01c1a72d05df1ec81f3759a8360042
2024-01-16 16:56:57 +0000 to 2024-01-17 17:26:41 +0000
- fix(json-msg): use pkgid spec in in JSON messages (rust-lang/cargo#13311)
- doc(features): Highlight the non-blocking feature gating technique (rust-lang/cargo#13307)
r? oli-obk
Could you check if this fixes miri build?
Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap
Since https://github.com/rust-lang/rust/pull/113906, all x.py invocations performed by rust-analyzer have RUSTC_BOOTSTRAP=1 set. This was to fix https://github.com/rust-lang/rust/issues/112391#issuecomment-1597224941 — rust-analyzer uses some default cargo from the system when fetching workspace layout, and the standard library uses some unstable cargo feature, so x.py would previously fail if the system toolchain wasn't nightly.
82e1608dfa/library/std/Cargo.toml (L1)
This PR changes x.py to cancel out this RUSTC_BOOTSTRAP=1 when compiling bootstrap. It will only remain set when running the compiled bootstrap executable. This fixes spurious bootstrap rebuilds in the event that a rust-analyzer x.py invocation is alternated with someone running x.py themself on the command line, if any dependency of bootstrap looks at `option_env!("RUSTC_BOOTSTRAP")`, which is the case since https://github.com/rust-lang/rust/pull/119654.
**Before:**
```console
$ RUSTC_BOOTSTRAP=1 ./x.py check library/core
Building bootstrap
Compiling proc-macro2 v1.0.76
Compiling quote v1.0.35
Compiling syn v2.0.48
Compiling clap_derive v4.4.7
Compiling serde_derive v1.0.195
Compiling clap v4.4.13
Compiling clap_complete v4.4.6
Compiling build_helper v0.1.0
Compiling bootstrap v0.0.0
Finished dev [unoptimized] target(s) in 6.31s
Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.23s
Build completed successfully in 0:00:07
$ ./x.py check library/core
Building bootstrap
Compiling proc-macro2 v1.0.76
Compiling quote v1.0.35
Compiling syn v2.0.48
Compiling clap_derive v4.4.7
Compiling serde_derive v1.0.195
Compiling clap v4.4.13
Compiling clap_complete v4.4.6
Compiling build_helper v0.1.0
Compiling bootstrap v0.0.0
Finished dev [unoptimized] target(s) in 5.30s
Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.25s
Build completed successfully in 0:00:06
```
**After:**
```console
$ RUSTC_BOOTSTRAP=1 ./x.py check library/core
Building bootstrap
Finished dev [unoptimized] target(s) in 0.06s
Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.14s
Build completed successfully in 0:00:01
$ ./x.py check library/core
Building bootstrap
Finished dev [unoptimized] target(s) in 0.04s
Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.13s
Build completed successfully in 0:00:01
```
tests: add sanity-check assembly test for every target
Fixes#119910.
Adds a basic assembly test checking that each target can produce assembly and update the target tier policy to require this.
cc rust-lang/compiler-team#655
r? `@wesleywiser`
Add way to express that no values are expected with check-cfg
This PR adds way to express no-values (no values expected) with `--check-cfg` by making empty `values()` no longer mean `values(none())` (internal: `&[None]`) and now be an empty list (internal: `&[]`).
### Context
Currently `--check-cfg` has a way to express that _any value is expected_ with `values(any())`, but has no way to do the inverse and say that _no value is expected_.
This would be particularly useful for build systems that control a config name and it's values as they could always declare a config name as expected and if in the current state they have values pass them and if not pass an empty list.
To give a more concrete example, Cargo `--check-cfg` currently needs to generate:
- `--check-cfg=cfg(feature, values(...))` for the case with declared features
- and `--check-cfg=cfg()` for the case without any features declared
This means that when there are no features declared, users will get an `unexpected config name` but from the point of view of Cargo the config name `feature` is expected, it's just that for now there aren't any values for it.
See [Cargo `check_cfg_args` function](92395d9010/src/cargo/core/compiler/mod.rs (L1263-L1281)) for more details.
### De-specializing *empty* `values()`
To solve this issue I propose that we "de-specialize" empty `values()` to no longer mean `values(none())` but to actually mean empty set/list. This is one of the last source of confusion for my-self and others with the `--check-cfg` syntax.
> The confusing part here is that an empty `values()` currently means the same as `values(none())`, i.e. an expected list of values with the _none_ variant (as in `#[cfg(name)]` where the value is none) instead of meaning an empty set.
Before the new `cfg()` syntax, defining the _none_ variant was only possible under certain circumstances, so in https://github.com/rust-lang/rust/pull/111068 I decided to make `values()` to mean the _none_ variant, but it is no longer necessary since https://github.com/rust-lang/rust/pull/119473 which introduced the `none()` syntax.
A simplified representation of the proposed "de-specialization" would be:
| Syntax | List/set of expected values |
|-----------------------------------------|-----------------------------|
| `cfg(name)`/`cfg(name, values(none()))` | `&[None]` |
| `cfg(name, values())` | `&[]` |
Note that I have my-self made the mistake of using an empty `values()` as meaning empty set, see https://github.com/rust-lang/cargo/pull/13011.
`@rustbot` label +F-check-cfg
r? `@petrochenkov`
cc `@epage`
Adds a basic assembly test checking that each target can produce assembly
and update the target tier policy to require this.
Signed-off-by: David Wood <david@davidtw.co>
The internal, unstable field of `Pin` can conflict with fields from the
inner type accessed via the `Deref` impl. Rename it from `pointer` to
`__pointer`, to make it less likely to conflict with anything else.
Update books
## rust-lang/nomicon
1 commits in f6bd083c4ccfc4ce6699b8b4154e3c45c5a27a8c..6bc2415218d4dd0cb01433d8320f5ccf79c343a1
2024-01-03 04:01:04 UTC to 2024-01-03 04:01:04 UTC
- Update an example of `thread_local` to use `local_key_cell_methods` (rust-lang/nomicon#438)
## rust-lang/reference
1 commits in 3565c7978cfc9662f5963b135690ff9cbbfa0318..8c77e8be9da1a9c70545556218d563c8d061f1fd
2024-01-08 15:16:51 UTC to 2024-01-08 15:16:51 UTC
- Document that <- is a single token (rust-lang/reference#1424)
## rust-lang/rust-by-example
4 commits in c0be6299e52e4164c30ba6f41bd0ad0aaee64972..ddf5cb0e6ee54ba2dd84c8ca3e1314120014e20d
2024-01-13 11:06:22 UTC to 2024-01-13 11:01:00 UTC
- Update attribute.md, (rust-lang/rust-by-example#1791)
- fix: typo `unusude` (rust-lang/rust-by-example#1797)
- Update print.md (rust-lang/rust-by-example#1796)
- Update alias.md (rust-lang/rust-by-example#1790)
## rust-lang/rustc-dev-guide
4 commits in d13e85152a977cd0bcaf583cf5f49e86225697de..4af29d1a7f64f88a36539662c6a84fe1fbe6cde1
2024-01-14 10:42:53 UTC to 2024-01-06 17:47:01 UTC
- Expand upon PR guidelines (rust-lang/rustc-dev-guide#1851)
- Correct the link to rust reference (rust-lang/rustc-dev-guide#1848)
- Explain the important concepts of exhaustiveness checking (rust-lang/rustc-dev-guide#1830)
- Add guide for rustdoc search implementation (rust-lang/rustc-dev-guide#1846)
