| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#142098 (Implement `int_format_into` feature)
- rust-lang/rust#143567 (Point to correct argument in Func Call when Self type fails trait bound)
- rust-lang/rust#143570 (consider nested cases for duplicate RPITIT)
- rust-lang/rust#143571 (remove `has_nested` from builtin candidates)
- rust-lang/rust#143586 (Fix wrong cache event query key)
- rust-lang/rust#143589 (const-block-as-pattern: do not refer to no-longer-existing nightly feature)
- rust-lang/rust#143608 (Fix in std::String docs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
remove `has_nested` from builtin candidates
it's no longer necessary
r? types
|
|
Add `ty_span` query
r? `@compiler-errors`
fixes diagnostic regressions from https://github.com/rust-lang/rust/pull/142030
Also uses the new query in `check_const_item`
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#132469 (Do not suggest borrow that is already there in fully-qualified call)
- rust-lang/rust#143340 (awhile -> a while where appropriate)
- rust-lang/rust#143438 (Fix the link in `rustdoc.md`)
- rust-lang/rust#143539 (Regression tests for repr ICEs)
- rust-lang/rust#143566 (Fix `x86_64-unknown-netbsd` platform support page)
- rust-lang/rust#143572 (Remove unused allow attrs)
- rust-lang/rust#143583 (`loop_match`: fix 'no terminator on block')
- rust-lang/rust#143584 (make `Machine::load_mir` infallible)
- rust-lang/rust#143591 (Fix missing words in future tracking issue)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Allow custom default address spaces and parse `p-` specifications in the datalayout string
Some targets, such as CHERI, use as default an address space different from the "normal" default address space `0` (in the case of CHERI, [200 is used](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-877.pdf)). Currently, `rustc` does not allow to specify custom address spaces and does not take into consideration [`p-` specifications in the datalayout string](https://llvm.org/docs/LangRef.html#langref-datalayout).
This patch tries to mitigate these problems by allowing targets to define a custom default address space (while keeping the default value to address space `0`) and adding the code to parse the `p-` specifications in `rustc_abi`. The main changes are that `TargetDataLayout` now uses functions to refer to pointer-related informations, instead of having specific fields for the size and alignment of pointers in the default address space; furthermore, the two `pointer_size` and `pointer_align` fields in `TargetDataLayout` are replaced with an `FxHashMap` that holds info for all the possible address spaces, as parsed by the `p-` specifications.
The potential performance drawbacks of not having ad-hoc fields for the default address space will be tested in this PR's CI run.
r? workingjubilee
|
|
|
|
|
|
|
|
default data address space
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
Remove `Symbol` from `Named` variant of `BoundRegionKind`/`LateParamRegionKind`
The `Symbol` is redundant, since we already store a `DefId` in the region variant. Instead, load the name via `item_name` when needed (which is almost always on the diagnostic path).
This introduces a `BoundRegionKind::NamedAnon` which is used for giving anonymous bound regions names, but which should only be used during pretty printing and error reporting.
|
|
Remove names_imported_by_glob_use query.
Based on https://github.com/rust-lang/rust/pull/143247
r? ``@ghost`` for perf
|
|
Port `#[non_exhaustive]` to the new attribute parsing infrastructure
Ports `non_exhaustive` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? ``@jdonszelmann``
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make metadata a workproduct and reuse it
This PR aims to skip the generation of metadata by reusing the infrastructure that already exists for compiled codegen-units, namely "workproducts".
This can yield substantial gains (~10%) when we can demonstrate that metadata does not change between an incremental session and the next. This is the case if the crate is unchanged, or if all the changes are in upstream crates and have no effect on it. This latter case is most interesting, as it arises regularly for users with several crates in their workspace.
TODO:
- [x] Materialize the fact that metadata encoding relies on the relative order of definitions;
- [x] Refactor the handling of doc links.
|
|
Remove `PointerLike` trait
r? oli-obk
|
|
|
|
|
|
Avoid depending on forever-red DepNode when encoding metadata.
Split from https://github.com/rust-lang/rust/pull/114669 for perf
r? `@petrochenkov`
|
|
|
|
avoid suggesting traits from private dependencies
fixes rust-lang/rust#142676
fixes rust-lang/rust#138191
r? ``@tgross35``
|
|
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
|
|
|
|
interpret: move the native call preparation logic into Miri
`@nia-e` has to do a bunch of changes to this logic for her native call ptrace work, and it's getting annoying that the logic is split between Miri and rustc. So this moves the logic to Miri, keeping just the generic traversal part in rustc. It is unfortunate that this means we have to expose `get_alloc_raw`/`get_alloc_raw_mut`... I hope the function name is scary enough to reduce the risk of misuse.
r? `@oli-obk`
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#131923 (Derive `Copy` and `Hash` for `IntErrorKind`)
- rust-lang/rust#138340 (Remove some unsized tuple impls now that we don't support unsizing tuples anymore)
- rust-lang/rust#141219 (Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`)
- rust-lang/rust#142212 (bootstrap: validate `rust.codegen-backends` & `target.<triple>.codegen-backends`)
- rust-lang/rust#142237 (Detect more cases of unused_parens around types)
- rust-lang/rust#142964 (Attribute rework: a parser for single attributes without arguments)
- rust-lang/rust#143070 (Rewrite `macro_rules!` parser to not use the MBE engine itself)
- rust-lang/rust#143235 (Assemble const bounds via normal item bounds in old solver too)
- rust-lang/rust#143261 (Feed `explicit_predicates_of` instead of `predicates_of`)
- rust-lang/rust#143276 (loop match: handle opaque patterns)
- rust-lang/rust#143306 (Add `track_caller` attributes to trace origin of Clippy lints)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
|
|
loop match: handle opaque patterns
tracking issue https://github.com/rust-lang/rust/issues/132306
fixes https://github.com/rust-lang/rust/issues/143203
I believe the `Opaque` comes up because the range pattern is invalid? Because we do handle float patterns already so those should be fine.
r? `@Nadrieril`
|
|
Feed `explicit_predicates_of` instead of `predicates_of`
Tiny nitpick, just avoiding needing to mark the `predicates_of` query as feedable since it's derived from `explicit_predicates_of`.
|
|
Don't recompute `DisambiguatorState` for every RPITIT in trait definition
The `associated_type_for_impl_trait_in_trait` currently needs to rerun the `RPITVisitor` for every RPITIT to compute its disambiguator.
Instead of synthesizing all of the RPITITs def ids one at a time in different queries, just synthesize them inside of the `associated_types_for_impl_traits_in_associated_fn` query. There we can just share the same `DisambiguatorState` for all the RPITITs in one function signature.
r? ``````@Zoxc`````` or ``````@oli-obk`````` cc rust-lang/rust#140453
|
|
|
|
|
|
|
|
Update stage0 to 1.89.0-beta.1
- Update version placeholders
- Update stage0 to 1.89.0-beta.1
- Update `STAGE0_MISSING_TARGETS`
- Update `cfg(bootstrap)`
r? `@Mark-Simulacrum`
try-job: dist-i586-gnu-i586-i686-musl
|
|
Remove support for `dyn*` from the compiler
This PR removes support for `dyn*` (https://github.com/rust-lang/rust/issues/102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).
It doesn't seem like we are going to need `dyn*` types -- even in an not-exposed-to-the-user way[^1] -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of `dyn*` types, I don't really see a compelling reason to have to maintain their implementation in the compiler.
[^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`.
We've learned quite a lot from `dyn*`, but I think at this point its current behavior leads to more questions than answers. For example, `dyn*` support today remains somewhat fragile; it ICEs in many cases where the current "normal" `dyn Trait` types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.
```rust
#![feature(dyn_star)]
trait Foo {
fn hello(self);
}
impl Foo for usize {
fn hello(self) {
println!("hello, world");
}
}
fn main() {
let x: dyn* Foo = 1usize;
x.hello();
}
```
And:
```rust
#![feature(dyn_star)]
trait Trait {
type Out where Self: Sized;
}
fn main() {
let x: <dyn* Trait as Trait>::Out;
}
```
...and probably many more problems having to do with the intersection of dyn-compatibility and `Self: Sized` bounds that I was too lazy to look into like:
* GATs
* Methods with invalid signatures
* Associated consts
Generally, `dyn*` types also end up getting in the way of working with [normal `dyn` types](https://github.com/rust-lang/rust/issues/102425#issuecomment-1712604409) to an extent that IMO outweighs the benefit of experimentation.
I recognize that there are probably other, more creative usages of `dyn*` that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between `dyn*` and dyn-compatibility before we think about reimplementing them in the type system.
---
I'm planning on removing the `DynKind` enum and the `PointerLike` built-in trait from the compiler after this PR lands.
Closes rust-lang/rust#102425.
cc `@eholk` `@rust-lang/lang` `@rust-lang/types`
Closes rust-lang/rust#116979.
Closes rust-lang/rust#119694.
Closes rust-lang/rust#134591.
Closes rust-lang/rust#104800.
|
|
|
|
|
|
mir: Mark `Statement` and `BasicBlockData` as `#[non_exhaustive]`
Ensure they are always created using constructors.
r? oli-obk
|
|
|
