| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Describe lifetime of call argument temporaries passed indirectly
Fixes #132014.
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#140066 (Stabilize `<[T; N]>::as_mut_slice` as `const`)
- rust-lang/rust#141105 (additional edge cases tests for `path.rs` 🧪 )
- rust-lang/rust#141487 (Update askama to `0.14.0`)
- rust-lang/rust#141498 (Use C-string literals to reduce boilerplate)
- rust-lang/rust#141505 (rename internal panicking::try to catch_unwind)
- rust-lang/rust#141511 (Cleanup CodegenFnAttrFlags)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
- Rename `USED` to `USED_COMPILER` to better reflect its behavior.
- Reorder some items to group the used and allocator flags together
- Renumber them without gaps
|
|
Use the fn_span when emitting function calls for better debug info.
This especially improves the developer experience for long chains of function calls that span multiple lines, which is common with builder patterns, chains of iterator/future combinators, etc.
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: arm-android
r? `@jieyouxu`
|
|
Rename `kw::Empty` as `sym::empty`.
Because the empty string is not a keyword.
r? `@petrochenkov`
|
|
This especially improves the developer experience for long chains
of function calls that span multiple lines, which is common with
builder patterns, chains of iterator/future combinators, etc.
|
|
|
|
Because the empty string is not a keyword.
|
|
make `rustc_attr_parsing` less dominant in the rustc crate graph
It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly.
Previous graph:
Graph with this PR:
The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*.
The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
|
|
bump windows crate for compiler,bootstrap and tools
This dedupes crate versions. For `x86_64-pc-windows-msvc` stage1 cuts few kb from `rustc_driver.dll`, nice.
|
|
|
|
turn lld warning on old gccs into info log
As discussed in #140964 and IRL, this PR switches the spammy warning shown unconditionally when an old gcc doesn't support `-fuse-ld=lld` and we retry linking without it, to an info debug log so we don't lose it.
r? `@Mark-Simulacrum`
Fixes #140964
|
|
|
|
|
|
Unfortunately, multiple people are reporting linker warnings related to
`__rust_no_alloc_shim_is_unstable` after this change. The solution isn't
quite clear yet, let's revert to green for now, and try a reland with a
determined solution for `__rust_no_alloc_shim_is_unstable`.
This reverts commit c8b7f32434c0306db5c1b974ee43443746098a92, reversing
changes made to 667247db71ea18c4130dd018d060e7f09d589490.
|
|
|
|
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is https://github.com/rust-lang/rust/commit/58651d1b316e268fac2100c3ae37bb502a36b8ba, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
|
|
|
|
|
|
remove 'unordered' atomic intrinsics
As their doc comment already indicates, these operations do not currently have a place in our memory model. The intrinsics were introduced to support a hack in compiler-builtins, but that hack recently got removed (see https://github.com/rust-lang/compiler-builtins/issues/788).
|
|
|
|
|
|
Use more accurate ELF flags on MIPS
Changes the MIPS ELF flags used for metadata objects to be closer to what LLVM uses so the linker doesn't complain
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
|
|
|
|
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
To support weird symbol names, including dots in particular.
|
|
shared-generics: Do not share instantiations that contain local-only types
In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet:
```rs
pub fn some_generic_function(_: impl Fn()) {}
pub fn non_generic_function() {
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
}
```
even though none of these instantiations can actually be created from outside of `non_generic_function`. This is a dummy example, but we do rely on invoking callbacks with FnOnce a lot in our codebase.
This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate.
This PR reduces incremental build time for Zed (touch editor.rs scenario) from 12.4s to 10.4s. I'd love to see a perf run if possible; per my checks this PR does not incur new instantiations in downstream crates, so if there'd be perf regressions, I'd expect them to come from newly-introduced visibility checks.
|
|
r=bjorn3
Issue an error when using `no_mangle` on language items
This pull requests adds the code to issue an error or a warning when using `no_mangle` on language items. This should detail why the `undefined symbol` error is issued for the code described in #139923.
The pull request adds two ui tests, one testing the error and the other one the warning.
I would love some feedback here, as I am not sure that the error and warning are issues using the right API.
|
|
Share the naked asm impl between cg_ssa and cg_clif
This was introduced in https://github.com/rust-lang/rust/pull/128004.
|
|
add suggestion on how to add a panic breakpoint
Co-authored-by: Pat Pannuto <pat.pannuto@gmail.com>
delete no_mangle from ui/panic-handler/panic-handler-wrong-location test
issue an error for the usage of #[no_mangle] on internal language items
delete the comments
add newline
rephrase note
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
update error not to leak implementation details
delete no_mangle_span
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
delete commented code
|
|
Simplify `LazyAttrTokenStream`
`LazyAttrTokenStream` is an unpleasant type: `Lrc<Box<dyn ToAttrTokenStream>>`. Why does it look like that?
- There are two `ToAttrTokenStream` impls, one for the lazy case, and one for the case where we already have an `AttrTokenStream`.
- The lazy case (`LazyAttrTokenStreamImpl`) is implemented in `rustc_parse`, but `LazyAttrTokenStream` is defined in `rustc_ast`, which does not depend on `rustc_parse`. The use of the trait lets `rustc_ast` implicitly depend on `rustc_parse`. This explains the `dyn`.
- `LazyAttrTokenStream` must have a `size_of` as small as possible, because it's used in many AST nodes. This explains the `Lrc<Box<_>>`, which keeps it to one word. (It's required `Lrc<dyn _>` would be a fat pointer.)
This PR moves `LazyAttrTokenStreamImpl` (and a few other token stream things) from `rustc_parse` to `rustc_ast`. This lets us replace the `ToAttrTokenStream` trait with a two-variant enum and also remove the `Box`, changing `LazyAttrTokenStream` to `Lrc<LazyAttrTokenStreamInner>`. Plus it does a few cleanups.
r? `@petrochenkov`
|
|
This commit does the following.
- Changes it from `Lrc<Box<dyn ToAttrTokenStream>>` to
`Lrc<LazyAttrTokenStreamInner>`.
- Reworks `LazyAttrTokenStreamImpl` as `LazyAttrTokenStreamInner`, which
is a two-variant enum.
- Removes the `ToAttrTokenStream` trait and the two impls of it.
The recursion limit must be increased in some crates otherwise rustdoc
aborts.
|
|
This was missed as part of [1].
[1]: https://github.com/rust-lang/rust/pull/140323
|
|
Implement the internal feature `cfg_target_has_reliable_f16_f128`
Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for the type works correctly. The `_math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.
These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is only intended to replace the build scripts for `std` tests and `compiler-builtins` that don't have any way to configure based on the codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
---
The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`. I omitted providing a `cfg(bootstrap)` configuration to keep things simpler since the next beta branch is in two weeks.
try-job: aarch64-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-ext2
|
|
of the current crate
In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate.
I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet:
```rs
pub fn some_generic_function(_: impl Fn()) {}
pub fn non_generic_function() {
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
}
```
even though none of these instantiations can actually be created from outside of `non_generic_function`.
This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate.
This PR reduces incremental build time for Zed (touch edito.rs scenario) from 12.4s to 10.4s.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
async_drop_in_place::{closure}, scoped async drop added.
|
|
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.
These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
|
|
If creating a temporary directory fails with permission denied then retry with backoff
On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI.
cc ```@jieyouxu,``` https://github.com/rust-lang/rust/issues/133959
|
|
On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI.
|
|
Make #![feature(let_chains)] bootstrap conditional in compiler/
Let chains have been stabilized recently in #132833, so we can remove the gating from our uses in the compiler (as the compiler uses edition 2024).
|
|
|
|
set subsections_via_symbols for ld64 helper sections
closes https://github.com/rust-lang/rust/issues/139744
cc `@madsmtm`
|
