| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Migrate `rlib-format-packed-bundled-libs-2`, `native-link-modifier-whole-archive` and `no-builtins-attribute` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
|
|
tidy: Fix quote in error message
I noticed that the backticks around the error code wasn't done properly in this string when I was building Rust 1.80.0 and found it is still this way in nightly. Example:
```
warning: Error code `E0595` needs to have at least one UI test in the `tests/error-codes/` directory`!
warning: Error code E0602`` has a UI test file, but doesn't contain its own error code!
warning: Error code `E0619` needs to have at least one UI test in the `tests/error-codes/` directory`!
```
This commit fixes it to match the other warning strings.
|
|
cargo-miri: better error when we seem to run inside bootstrap but something is wrong
Cc https://github.com/rust-lang/miri/issues/3775
|
|
Mark `Parser::eat`/`check` methods as `#[must_use]`
These methods return a `bool`, but we probably should either use these values or explicitly throw them away (e.g. when we just want to unconditionally eat a token if it exists).
I changed a few places from `eat` to `expect`, but otherwise I tried to leave a comment explaining why the `eat` was okay.
This also adds a test for the `pattern_type!` macro, which used to silently accept a missing `is` token.
|
|
Bump bootstrap compiler to new beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
allow overwriting the output of `rustc --version`
Our wonderful bisection folk [have to work around](https://github.com/rust-lang/rust/issues/123276#issuecomment-2075001510) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for.
This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by
* choosing when to update rustc
* choosing when to update dependencies
* choosing which nightly features they are willing to take the breakage for
The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency.
This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too.
This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by https://github.com/rust-lang/cargo-bisect-rustc/pull/335.
I mainly want to establish a compiler team policy:
> We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to.
Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection.
I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
|
|
This reverts commit c81a40bbc02bb44aa99b3a94322dbf07e7a62ce1.
|
|
|
|
|
|
|
|
is wrong
|
|
r=GuillaumeGomez
rustdoc: word wrap CamelCase in the item list table and sidebar
This is an alternative to https://github.com/rust-lang/rust/pull/126209. That is, it fixes the issue that affects the very long type names in https://docs.rs/async-stripe/0.31.0/stripe/index.html#structs.
This is, necessarily, a pile of nasty heuristics. We need to balance a few issues:
- Sometimes, there's no real word break. For example, `BTreeMap` should be `BTree<wbr>Map`, not `B<wbr>Tree<wbr>Map`.
- Sometimes, there's a legit word break, but the name is tiny and the HTML overhead isn't worth it. For example, if we're typesetting `TyCtx`, writing `Ty<wbr>Ctx` would have an HTML overhead of 50%. Line breaking inside it makes no sense.
# Screenshots
| Before | After |
| ------ | ----- |
|  | 
|
|
|
|
|
|
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
miri: fix offset_from behavior on wildcard pointers
offset_from wouldn't behave correctly when the "end" pointer was a wildcard pointer (result of an int2ptr cast) just at the end of the allocation. Fix that by expressing the "same allocation" check in terms of two `check_ptr_access_signed` instead of something specific to offset_from, which is both more canonical and works better with wildcard pointers.
The second commit just improves diagnostics: I wanted the "pointer is dangling (has no provenance)" message to say how many bytes of memory it expected to see (since if it were 0 bytes, this would actually be legal, so it's good to tell the user that it's not 0 bytes). And then I was annoying that the error looks so different for when you deref a dangling pointer vs an out-of-bounds pointer so I made them more similar.
Fixes https://github.com/rust-lang/miri/issues/3767
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
deps: dedup object, wasmparser, wasm-encoder
* dedups one `object`, additional dupe will be removed, with next `thorin-dwp` update
* `wasmparser` pinned to minor versions, so full merge isn't possible
* same with `wasm-encoder`
Turned off some features for `wasmparser` (see features https://github.com/bytecodealliance/wasm-tools/blob/v1.208.1/crates/wasmparser/Cargo.toml) in `run-make-support`, looks working?
|
|
waiting on thorin-dwp update
dedup one wasmparser
run-make-support: drop some features for wasmparser
dedupe wasm-encoder
|
|
Update the reference
This updates the reference to use the new mdbook-spec preprocessor, which is a Cargo library inside the reference submodule.
Note that this PR contains a bunch of bootstrap cleanup commits to assist with making sure the submodules are working correctly. All of the cleanup PRs should have a description in their commit. I'd be happy to move those to a separate PR if that makes review easier.
The main changes for the reference are:
- Move the `doc::Reference` bootstrap step out of the generic macro into a custom step.
- This step needs to build rustdoc because the new mdbook-spec plugin uses rustdoc for generating links.
- PATH is updated so that the rustdoc binary can be found.
- rustbook now includes the mdbook-spec plugin as a dependency.
- rustbook enables the mdbook-spec preprocessor.
I did a bunch of testing with the various commands and setups, such as:
- `submodules=true` and `submodules=false`
- having all submodules deinitialized
- not in a git repository
However, there are probably thousands of different permutations of different commands, settings, and environments, so there is a chance I'm missing something.
|
|
Stabilize `is_sorted`
Closes: https://github.com/rust-lang/rust/issues/53485.
~~Question: does~~ https://github.com/rust-lang/rust/blob/8fe0c753f23e7050b87a444b6622caf4d2272d5d/compiler/rustc_lint_defs/src/builtin.rs#L1986-L1994 ~~need a new example?~~
edit: It causes a test failure and needs to be changed anyway.
``@rustbot`` label: +T-libs-api
r? libs-api
|
|
Add a README to rustbook to explain its purpose
This adds a README to the rustbook tool to help explain what it is for and how to use it.
|
|
Migrate `static-dylib-by-default`, `sanitizer-dylib-link`, `sanitizer-cdylib-link` and `sanitizer-staticlib-link` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: armhf-gnu
try-job: test-various
try-job: i686-msvc
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
|
|
Update cargo
14 commits in 5f6b9a92201d78af75dc24f14662c3e2dacbbbe1..b5d44db1daf0469b227a6211b987162a39a54730
2024-07-19 18:09:17 +0000 to 2024-07-26 21:27:12 +0000
- Package workspaces (rust-lang/cargo#13947)
- test: migrate messages to snapbox (rust-lang/cargo#14242)
- chore: Update dependencies (rust-lang/cargo#14299)
- fix: remove rustc probe for `--check-cfg` support (rust-lang/cargo#14302)
- Misc test clean up (rust-lang/cargo#14297)
- Don't downgrade on prerelease `VersionReq` when update with --breaking. (rust-lang/cargo#14250)
- test: Migrate some json tests to snapbox (rust-lang/cargo#14293)
- Revert "fix: Ensure dep/feature activates the dependency on 2024" (rust-lang/cargo#14295)
- chore: bump cargo-test-support to 0.4.0 (rust-lang/cargo#14286)
- Bump to 0.83.0; update changelog (rust-lang/cargo#14285)
- Improved error message when `update --breaking` invalid spec. (rust-lang/cargo#14279)
- docs(test): Expand documentation of cargo-test-support (rust-lang/cargo#14272)
- test: Fix some test based on rustc version (rust-lang/cargo#14282)
- Use `Rc` instead of `Arc` for storing rustflags (rust-lang/cargo#14273)
r? ghost
|
|
|
|
|
|
build-manifest: Allow building manifests for formats that only have xz compression
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize const `{integer}::from_str_radix` i.e. `const_int_from_str`
This PR stabilizes the feature `const_int_from_str`.
- ACP Issue: rust-lang/libs-team#74
- Implementation PR: rust-lang/rust#99322
- Part of Tracking Issue: rust-lang/rust#59133
API Change Diff:
```diff
impl {integer} {
- pub fn from_str_radix(src: &str, radix: u32) -> Result<Self, ParseIntError>;
+ pub const fn from_str_radix(src: &str, radix: u32) -> Result<Self, ParseIntError>;
}
impl ParseIntError {
- pub fn kind(&self) -> &IntErrorKind;
+ pub const fn kind(&self) -> &IntErrorKind;
}
```
This makes it easier to parse integers at compile-time, e.g.
the example from the Tracking Issue:
```rust
env!("SOMETHING").parse::<usize>().unwrap()
```
could now be achived with
```rust
match usize::from_str_radix(env!("SOMETHING"), 10) {
Ok(val) => val,
Err(err) => panic!("Invalid value for SOMETHING environment variable."),
}
```
rather than having to depend on a library that implements or manually implement the parsing at compile-time.
---
Checklist based on [Libs Stabilization Guide - When there's const involved](https://std-dev-guide.rust-lang.org/development/stabilization.html#when-theres-const-involved)
I am treating this as a [partial stabilization](https://std-dev-guide.rust-lang.org/development/stabilization.html#partial-stabilizations) as it shares a tracking issue (and is rather small), so directly opening the partial stabilization PR for the subset (feature `const_int_from_str`) being stabilized.
- [x] ping Constant Evaluation WG
- [x] no unsafe involved
- [x] no `#[allow_internal_unstable]`
- [ ] usage of `intrinsic::const_eval_select` rust-lang/rust#124625 in `from_str_radix_assert` to change the error message between compile-time and run-time
- [ ] [rust-labg/libs-api FCP](https://github.com/rust-lang/rust/pull/124941#issuecomment-2207021921)
|
|
Support ?Trait bounds in supertraits and dyn Trait under a feature gate
This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example:
```rust
#![feature(allow_maybe_polarity)]
...
trait Trait1 : ?Trait { ... } // ok
fn foo(_: Box<(dyn Trait2 + ?Trait)>) {} // ok
fn bar<T: ?Sized + ?Trait>(_: &T) {} // ok
```
Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762).
This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Insert FileDescription instead of FileDescriptor in ``insert_fd``
This PR moves the creation of ``FileDescriptor`` inside ``insert_fd``, and ``insert_fd`` now takes in ``FileDescription`` instead of ``FileDescriptor``. This change is needed by #3712.
|
|
|
|
better diagnostics for Tree Borrows + int2ptr casts
- Entirely reject `-Zmiri-permissive-provenance -Zmiri-tree-borrows` since that combination just doesn't work
- In the int2ptr cast warning, when Tree Borrows is enabled, do not recommend `-Zmiri-permissive-provenance`, instead note that Tree Borrows does not support int2ptr casts
Fixes https://github.com/rust-lang/miri/issues/3764
|
