Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
We only use mir_for_ctfe for them anyway in instance_mir. This does
prevent MIR inlining of constructor calls, but constructor calls that
are inlinable during MIR optimizations are rare anyway given that MIR
building already inlines all direct calls to constructors.
link modifier `export-symbols`: export all global symbols from selected uptream c static libraries
In order to be able to export symbols from a specified upstream C static library, I redesigned a solution that, compared to a previous PR rust-lang/rust#150335 I submitted, will not have any extra symbols leaking out.
The following points should be noted:
- This attribute will select and import the `Global` symbols of the first matching library it finds.
- Developers should ensure that there are no libraries with the same name.
- This modifier is only compatible with `static` linking kind
- By default, upstream C static libraries will not export their `Global` symbols regardless of whether `LTO` optimization is enabled. However, after enabling this attribute, if the upstream C static library has `LTO` optimization enabled, the compiler will issue an error to inform the developer that the linked C library is invalid.
The test code is the same as the PR rust-lang/rust#150335.
Here are the results:
1. `cargo +include-libs rustc --release -- -L. -lstatic:+export-symbols=c_add`
(or you can use `#[link(name = "c_add", kind= "static", modifier = "+export-symbols")]` in the file)
```bash
U abort@GLIBC_2.2.5
U bcmp@GLIBC_2.2.5
0000000000014f60 T c_add
U calloc@GLIBC_2.2.5
U close@GLIBC_2.2.5
0000000000014f70 T c_sub
w __cxa_finalize@GLIBC_2.2.5
w __cxa_thread_atexit_impl@GLIBC_2.18
U dl_iterate_phdr@GLIBC_2.2.5
0000000000014ee0 T downstream_add
U __errno_location@GLIBC_2.2.5
U free@GLIBC_2.2.5
U fstat64@GLIBC_2.33
U getcwd@GLIBC_2.2.5
U getenv@GLIBC_2.2.5
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U lseek64@GLIBC_2.2.5
U malloc@GLIBC_2.2.5
U memcpy@GLIBC_2.14
U memmove@GLIBC_2.2.5
U memset@GLIBC_2.2.5
U mmap64@GLIBC_2.2.5
U munmap@GLIBC_2.2.5
U open64@GLIBC_2.2.5
U posix_memalign@GLIBC_2.2.5
U pthread_key_create@GLIBC_2.34
U pthread_key_delete@GLIBC_2.34
U pthread_setspecific@GLIBC_2.34
U read@GLIBC_2.2.5
U readlink@GLIBC_2.2.5
U realloc@GLIBC_2.2.5
U realpath@GLIBC_2.3
U stat64@GLIBC_2.33
w statx@GLIBC_2.28
U strlen@GLIBC_2.2.5
U syscall@GLIBC_2.2.5
U __tls_get_addr@GLIBC_2.3
U _Unwind_Backtrace@GCC_3.3
U _Unwind_DeleteException@GCC_3.0
U _Unwind_GetDataRelBase@GCC_3.0
U _Unwind_GetIP@GCC_3.0
U _Unwind_GetIPInfo@GCC_4.2.0
U _Unwind_GetLanguageSpecificData@GCC_3.0
U _Unwind_GetRegionStart@GCC_3.0
U _Unwind_GetTextRelBase@GCC_3.0
U _Unwind_RaiseException@GCC_3.0
U _Unwind_Resume@GCC_3.0
U _Unwind_SetGR@GCC_3.0
U _Unwind_SetIP@GCC_3.0
U write@GLIBC_2.2.5
U writev@GLIBC_2.2.5
```
3. `cargo +nightly rustc --release -- -L ./`
```bash
U abort@GLIBC_2.2.5
U bcmp@GLIBC_2.2.5
U calloc@GLIBC_2.2.5
U close@GLIBC_2.2.5
w __cxa_finalize@GLIBC_2.2.5
w __cxa_thread_atexit_impl@GLIBC_2.18
U dl_iterate_phdr@GLIBC_2.2.5
0000000000011e10 T downstream_add
U __errno_location@GLIBC_2.2.5
U free@GLIBC_2.2.5
U fstat64@GLIBC_2.33
U getcwd@GLIBC_2.2.5
U getenv@GLIBC_2.2.5
w gettid@GLIBC_2.30
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U lseek64@GLIBC_2.2.5
U malloc@GLIBC_2.2.5
U memcpy@GLIBC_2.14
U memmove@GLIBC_2.2.5
U memset@GLIBC_2.2.5
U mmap64@GLIBC_2.2.5
U munmap@GLIBC_2.2.5
U open64@GLIBC_2.2.5
U posix_memalign@GLIBC_2.2.5
U pthread_key_create@GLIBC_2.34
U pthread_key_delete@GLIBC_2.34
U pthread_setspecific@GLIBC_2.34
U read@GLIBC_2.2.5
U readlink@GLIBC_2.2.5
U realloc@GLIBC_2.2.5
U realpath@GLIBC_2.3
U stat64@GLIBC_2.33
w statx@GLIBC_2.28
U strlen@GLIBC_2.2.5
U syscall@GLIBC_2.2.5
U __tls_get_addr@GLIBC_2.3
U _Unwind_Backtrace@GCC_3.3
U _Unwind_GetDataRelBase@GCC_3.0
U _Unwind_GetIP@GCC_3.0
U _Unwind_GetIPInfo@GCC_4.2.0
U _Unwind_GetLanguageSpecificData@GCC_3.0
U _Unwind_GetRegionStart@GCC_3.0
U _Unwind_GetTextRelBase@GCC_3.0
U _Unwind_RaiseException@GCC_3.0
U _Unwind_Resume@GCC_3.0
U _Unwind_SetGR@GCC_3.0
U _Unwind_SetIP@GCC_3.0
U write@GLIBC_2.2.5
U writev@GLIBC_2.2.5
```
r? @bjorn3
Port #[needs_allocator] to attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Ports needs_allocator attribute to the new attribute parser.
Note: this is a deprecated and feature gated attribute.
We want to evaluate the rhs of a type_const.
Also added an early return/guard in eval_in_interpreter which is used in functions like `eval_to_allocation_raw_provider`
Lastly add a debug assert to `thir_body()` if we have gotten there with a type_const something as gone wrong.
Get rid of a call to is_type_const() and instead use a match arm.
Change this is_type_const() check to a debug_assert!()
Change to use an if else statment instead.
Update type_const-pub.rs
Fix formatting.
Noticed that this is the same check as is_type_const() centralize it.
Add test case for pub type_const.
Remove `Deref`/`DerefMut` impl for `Providers`.
It's described as a "backwards compatibility hack to keep the diff small". Removing it requires only a modest amount of churn, and the resulting code is clearer without the invisible derefs.
r? @oli-obk
It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
Remove a workaround for a bug (take 2)
I don't think it is necessary anymore. As I understand it from issue 39504 the original problem was that rustbuild changed a hardlink in the cargo build dir to point to copy in the sysroot while cargo may have hardlinked it to the original first. I don't think this happens anymore and as such this workaround is no longer necessary
I can't reproduce the CI failure in https://github.com/rust-lang/rust/pull/122186 locally with `./x.py test library/core`. It is possible this got fixed by https://github.com/rust-lang/rust/pull/149273.
mGCA: Support array expression as direct const arguments
tracking issue: rust-lang/rust#132980resolve: rust-lang/rust#150612
Support array expression as direct const arguments (e. g. [1, 2, N]) in min_generic_const_args.
todo:
* [x] Rebase another mGCA PR
* [x] Add more test case
* [x] Modify clippy code
I don't think it is necessary anymore. As I understand it from issue
39504 the original problem was that rustbuild changed a hardlink in the
cargo build dir to point to copy in the sysroot while cargo may have
hardlinked it to the original first. I don't think this happens anymore
and as such this workaround is no longer necessary.
MGCA: Support for tuple constructors
r? BoxyUwU
part of https://github.com/rust-lang/rust/issues/132980fixesrust-lang/rust#136379fixesrust-lang/rust#138132
i tried to keep implementation very minimal and it's very similar to how structs was implemented with small adjustments
this does not make const constructor like None works, just something like Some(n)
todo:
* ~~tests~~
* write a better description (not sure if needed)
* add more comments and FIXMEs from structs code
Detect cases where `?` is applied on a type that could be coming from a different crate version than expected
```
error[E0277]: `?` couldn't convert the error to `dependency::Error`
--> replaced
|
LL | fn main() -> Result<(), Error> {
| ----------------- expected `dependency::Error` because of this
...
LL | Err(Error2)?;
| -----------^ the trait `From<Error2>` is not implemented for `dependency::Error`
| |
| this can't be annotated with `?` because it has type `Result<_, Error2>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: the trait `From<Error2>` is not implemented for `dependency::Error`
but trait `From<()>` is implemented for it
--> replaced
|
LL | impl From<()> for Error {
| ^^^^^^^^^^^^^^^^^^^^^^^
= help: for that trait implementation, expected `()`, found `Error2`
= note: there are multiple different versions of crate `dependency` in the dependency graph
= help: you can use `cargo tree` to explore your dependency tree
```
The existing checks rely on having access to the actual types/traits that diverged to detect they are called the same, come from different crates with the same name. The new check is less specific, merely looking to see if the crate name the involved type belongs has multiple crates.
CC rust-lang/rust#78552.
```
error[E0277]: `?` couldn't convert the error to `dependency::Error`
--> replaced
|
LL | fn main() -> Result<(), Error> {
| ----------------- expected `dependency::Error` because of this
...
LL | Err(Error2)?;
| -----------^ the trait `From<Error2>` is not implemented for `dependency::Error`
| |
| this can't be annotated with `?` because it has type `Result<_, Error2>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: the trait `From<Error2>` is not implemented for `dependency::Error`
but trait `From<()>` is implemented for it
--> replaced
|
LL | impl From<()> for Error {
| ^^^^^^^^^^^^^^^^^^^^^^^
= help: for that trait implementation, expected `()`, found `Error2`
= note: there are multiple different versions of crate `dependency` in the dependency graph
= help: you can use `cargo tree` to explore your dependency tree
```
The existing checks rely on having access to the actual types/traits that diverged to detect they are called the same, come from different crates with the same name. The new check is less specific, merely looking to see if the crate name the involved type belongs has multiple crates.
Improve missing core error for tier 3 targets
Tier 3 targets can't be installed via rustup, so don't recommend that. Additionally, do recommend build-std on stable because it's the recommended way to use these targets, people should switch to nightly.
Tier 3 targets can't be installed via rustup, so don't recommend that.
Additionally, do recommend build-std on stable because it's the
recommended way to use these targets, people should switch to nightly.
Prefer remapping the relative `library/` and `compiler/` directories
This is done to avoid leaking the relative paths to the standard library after the overall of filenames in rust-lang/rust#149709.
Noted that the paths were already leaking before, but to a lesser extent since most (but not all) the paths embedded in the distributed `rlib` were absolute.
In general Cargo compiles workspace members with relative paths, so it's better anyway to remap the relative path.
In addition to our tests I have manually confirmed that it also works as expected for the printed diagnostics paths.
cf. https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/remapping.20of.20the.20standard.20library/near/564093571
