| Age | Commit message (Collapse) | Author | Lines |
|---|
|
New const traits syntax
This PR only affects the AST and doesn't actually change anything semantically.
All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser
Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error
r? ``@fee1-dead``
cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
|
|
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
|
|
Fast path for WF goals in new solver
Hopefully self-explanatory.
|
|
Rollup of 18 pull requests
Successful merges:
- rust-lang/rust#137843 (make RefCell unstably const)
- rust-lang/rust#140942 (const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns)
- rust-lang/rust#142549 (small iter.intersperse.fold() optimization)
- rust-lang/rust#142637 (Remove some glob imports from the type system)
- rust-lang/rust#142647 ([perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation)
- rust-lang/rust#142700 (Remove incorrect comments in `Weak`)
- rust-lang/rust#142927 (Add note to `find_const_ty_from_env`)
- rust-lang/rust#142967 (Fix RwLock::try_write documentation for WouldBlock condition)
- rust-lang/rust#142986 (Port `#[export_name]` to the new attribute parsing infrastructure)
- rust-lang/rust#143001 (Rename run always )
- rust-lang/rust#143010 (Update `browser-ui-test` version to `0.20.7`)
- rust-lang/rust#143015 (Add `sym::macro_pin` diagnostic item for `core::pin::pin!()`)
- rust-lang/rust#143033 (Expand const-stabilized API links in relnotes)
- rust-lang/rust#143041 (Remove cache for citool)
- rust-lang/rust#143056 (Move an ACE test out of the GCI directory)
- rust-lang/rust#143059 (Fix 1.88 relnotes)
- rust-lang/rust#143067 (Tracking issue number for `iter_macro`)
- rust-lang/rust#143073 (Fix some fixmes that were waiting for let chains)
Failed merges:
- rust-lang/rust#143020 (codegen_fn_attrs: make comment more precise)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add note to `find_const_ty_from_env`
Add a note to `find_const_ty_from_env` to explain why it has an `unwrap` which "often" causes ICEs.
Also, uplift it into the new trait solver. This avoids needing to go through the interner to call this method which is otherwise an inherent method in the compiler. I can remove this part if desired.
r? `@boxyuwu`
|
|
such constants as patterns
|
|
make `tidy-alphabetical` use a natural sort
The idea here is that these lines should be correctly sorted, even though a naive string comparison would say they are not:
```
foo2
foo10
```
This is the ["natural sort order"](https://en.wikipedia.org/wiki/Natural_sort_order).
There is more discussion in [#t-compiler/help > tidy natural sort](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tidy.20natural.20sort/with/519111079)
Unfortunately, no standard sorting tools are smart enough to to this automatically (casting some doubt on whether we should make this change). Here are some sort outputs:
```
> cat foo.txt | sort
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -n
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -V
foo
foo1
foo2
foo10
mp
mp1e2
np1e2",
np",
```
Disappointingly, "numeric" sort does not actually have the behavior we want. It only sorts by numeric value if the line starts with a number. The "version" sort looks promising, but does something very unintuitive if you look at the final 4 values. None of the other options seem to have the desired behavior in all cases:
```
-b, --ignore-leading-blanks ignore leading blanks
-d, --dictionary-order consider only blanks and alphanumeric characters
-f, --ignore-case fold lower case to upper case characters
-g, --general-numeric-sort compare according to general numerical value
-i, --ignore-nonprinting consider only printable characters
-M, --month-sort compare (unknown) < 'JAN' < ... < 'DEC'
-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)
-n, --numeric-sort compare according to string numerical value
-R, --random-sort shuffle, but group identical keys. See shuf(1)
--random-source=FILE get random bytes from FILE
-r, --reverse reverse the result of comparisons
--sort=WORD sort according to WORD:
general-numeric -g, human-numeric -h, month -M,
numeric -n, random -R, version -V
-V, --version-sort natural sort of (version) numbers within text
```
r? ```@Noratrieb``` (it sounded like you know this code?)
|
|
|
|
|
|
workingjubilee:doubt-that-cmse-nonsecure-abis-always-match-c, r=compiler-errors
Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"`
We currently claim that `extern "C-cmse-nonsecure-*"` ABIs will always match `extern "C"`, but that seems... **optimistic** when one considers that `extern "C"` is ambiguous enough to be redefined in ways we may not want the Cortex M Security Extensions ABIs to mirror. If some configuration, feature, or other platform quirk that applied to Arm CPUs with CMSE would modify the `extern "C"` ABI, it does not seem like we should guarantee that also applies to the `extern "cmse-nonsecure-*"` ABIs. Anything involving target modifiers that might affect register availability or usage could make us liars if, for instance, clang decides those apply to normal C functions but not ones with the CMSE attributes, but we still want to have interop with the C compiler.
We simply do not control enough of the factors involved to both force these ABIs to match and still provide useful interop, so we shouldn't implicitly promise they do. We should leave this judgement call to the decisions of platform experts who can afford to keep up with the latest news from Cambridge, instead of enshrining today's hopeful guess forever in Rust's permitted ABIs.
It's a bit weird anyways.
- The attributes are `__attribute__((cmse_nonsecure_call))` and `__attribute__((cmse_nonsecure_entry))`, so the obvious choice is `extern "cmse-nonsecure-call"` and `extern "cmse-nonsecure-entry"`.
- We do not prefix any other ABI that reflects (or even *is*) a C ABI with "C-", with the exception of the Rust-defined `extern "C-unwind`", e.g. we do not have `extern "C-aapcs"` or `extern "C-sysv64"`.
Tracking issues:
- rust-lang/rust#75835
- rust-lang/rust#81391
|
|
Apply `impl_super_outlives` optimization to new trait solver
I never did rust-lang/rust#128746 for the new solver.
r? lcnr
|
|
|
|
|
|
|
|
|
|
|
|
Use gen blocks in the compiler instead of `from_coroutine`
r? oli-obk
|
|
Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`
This PR moves [`rustc_rayon_core`](https://github.com/rust-lang/rustc-rayon/tree/5fadf44/rayon-core) from commit `5fadf44` as suggested in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Bringing.20.60rustc_rayon_core.60.20in.20tree). I tried to split the work into separate commits so it is easy to review. The first commit is a simple copy and paste from the fork, and subsequent changes were made to use the new crate and to ensure the new crate complies with different format and lint expectations.
**Call-out:** I was also wondering if I need to make any further changes to accommodate licensing requirements.
r? oli-obk
|
|
|
|
[perf] Cache the canonical *instantiation* of param-envs
r? lcnr
|
|
Reduce uses of `hir_crate`.
I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely.
The second commit is a drive-by cleanup. It can be pulled into its own PR.
r? ````@oli-obk````
|
|
|
|
|
|
Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs
Fixes rust-lang/rust#108491
Fixes rust-lang/rust#125879
This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE
Fixes rust-lang/rust#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixes rust-lang/rust#138131
Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality.
This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful.
I'm not really sure how this interacts with rust-lang/rust#126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that.
r? `@compiler-errors`
cc `@fmease`
|
|
|
|
|
|
|
|
Extend the fast path for `Sized` traits to include constness and
`MetaSized`.
|
|
When `sized_hierarchy` is enabled, rustc should print `MetaSized` or
`PointeeSized` instead of `?Sized` in opaques.
|
|
Opting-out of `Sized` with `?Sized` is now equivalent to adding a
`MetaSized` bound, and adding a `MetaSized` or `PointeeSized` bound
is equivalent to removing the default `Sized` bound - this commit
implements this change in `rustc_hir_analysis::hir_ty_lowering`.
`MetaSized` is also added as a supertrait of all traits, as this is
necessary to preserve backwards compatibility.
Unfortunately, non-global where clauses being preferred over item bounds
(where `PointeeSized` bounds would be proven) - which can result in
errors when a `PointeeSized` supertrait/bound/predicate is added to some
items. Rather than `PointeeSized` being a bound on everything, it can
be the absence of a bound on everything, as `?Sized` was.
|
|
As core uses an extern type (`ptr::VTable`), the default `?Sized` to
`MetaSized` migration isn't sufficient, and some code that previously
accepted `VTable` needs relaxed to continue to accept extern types.
Similarly, the compiler uses many extern types in `rustc_codegen_llvm`
and in the `rustc_middle::ty::List` implementation (`OpaqueListContents`)
some bounds must be relaxed to continue to accept these types.
Unfortunately, due to the current inability to relax `Deref::Target`,
some of the bounds in the standard library are forced to be stricter than
they ideally would be.
|
|
Expand the automatic implementation of `MetaSized` and `PointeeSized` so
that it is also implemented on non-`Sized` types, just not `ty::Foreign`
(extern type).
|
|
Introduce the `MetaSized` and `PointeeSized` traits as supertraits of
`Sized` and initially implement it on everything that currently
implements `Sized` to isolate any changes that simply adding the
traits introduces.
|
|
r=workingjubilee,saethlin
Move metadata object generation for dylibs to the linker code
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
Prerequisite of https://github.com/rust-lang/rust/issues/96708.
|
|
Remove wasm legacy abi
Closes https://github.com/rust-lang/rust/issues/122532
Closes https://github.com/rust-lang/rust/issues/138762
Fixes https://github.com/rust-lang/rust/issues/71871
https://github.com/rust-lang/rust/issues/88152
Fixes https://github.com/rust-lang/rust/issues/115666
Fixes https://github.com/rust-lang/rust/issues/129486
|
|
[perf] `GenericArgs`-related: Change asserts to debug asserts & use more slice interning over iterable interning
1. The 1st commit yields the following perf gains: [#142289 (comment)](https://github.com/rust-lang/rust/pull/142289#issuecomment-2964041303).
2. The 2nd commit might also have a minor positive perf impact, however that one wasn't tested in isolation.
For reference, the initial approach https://github.com/rust-lang/rust/commit/c7e6accd79d91fe5dec01a81499a08f9db280440 (results: https://github.com/rust-lang/rust/pull/142289#issuecomment-2961076587) had a lot more changes (apart from what's now contained in commit 1 and 2) which seemed to be perf irrelevant (cf. the partial countercheck in https://github.com/rust-lang/rust/commit/6f82bf1cfece61d32714fbfeecf8c5cf1356b3ae (results: https://github.com/rust-lang/rust/pull/142289#issuecomment-2968393647).
|
|
|
|
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixes rust-lang/rust#79409
|
|
Delay replacing escaping bound vars in `FindParamInClause`
By uplifting the `BoundVarReplacer`, which is used by (e.g.) normalization to replace escaping bound vars that are encountered when folding binders, we can use a similar strategy to delay the instantiation of a binder's contents in the `FindParamInClause` used by the new trait solver.
This should alleviate the recently added requirement that `Binder<T>: TypeVisitable` only if `T: TypeFoldable`, which was previously required b/c we were calling `enter_forall` so that we could structurally normalize aliases that we found within the predicates of a param-env clause.
r? lcnr
|
|
|
|
|
|
abstraction
|
|
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
|
|
|
|
|
|
|
|
|
|
lint on duplicates during attribute parsing
To do this we stuff them in the diagnostic context to be emitted after
hir is constructed
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#141967 (Configure bootstrap backport nominations through triagebot)
- rust-lang/rust#142042 (Make E0621 missing lifetime suggestion verbose)
- rust-lang/rust#142272 (tests: Change ABIs in tests to more future-resilient ones)
- rust-lang/rust#142282 (Only run `citool` tests on the `auto` branch)
- rust-lang/rust#142297 (Implement `//@ needs-target-std` compiletest directive)
- rust-lang/rust#142298 (Make loongarch-none target maintainers more easily pingable)
- rust-lang/rust#142306 (Dont unwrap and re-wrap typing envs)
- rust-lang/rust#142324 (Remove unneeded `FunctionCx` from some codegen methods)
- rust-lang/rust#142328 (feat: Add `bit_width` for unsigned integer types)
Failed merges:
- rust-lang/rust#141639 (Expose discriminant values in stable_mir)
r? `@ghost`
`@rustbot` modify labels: rollup
|
