| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
[MIR] Deaggregate structs to enable further optimizations
Currently, we generate MIR like:
```
tmp0 = ...;
tmp1 = ...;
tmp3 = Foo { a: ..., b: ... };
```
This PR implements "deaggregation," i.e.:
```
tmp3.0 = ...
tmp3.1 = ...
```
Currently, the code only deaggregates structs, not enums. My understanding is that we do not have MIR to set the discriminant of an enum.
|
|
Properly enforce the "patterns aren't allowed in foreign functions" rule
Cases like `arg @ PATTERN` or `mut arg` were missing.
Apply the same rule to function pointer types.
Closes https://github.com/rust-lang/rust/issues/35203
[breaking-change], no breakage in sane code is expected though
r? @nikomatsakis
This is somewhat related to https://github.com/rust-lang/rfcs/pull/1685 (cc @matklad).
The goal is to eventually support full pattern syntax where it makes sense (function body may present) and to support *only* the following forms - `TYPE`, `ident: TYPE`, `_: TYPE` - where patterns don't make sense (function body doesn't present), i.e. in foreign functions and function pointer types.
|
|
Clarify UnsafeCell docs; fix #34496
None
|
|
|
|
|
|
Audit C++ types in rustllvm
cc @eddyb
Fixes #35131
|
|
|
|
|
|
|
|
|
|
the code has no tests and will just bitrot by itself.
this is a [breaking-change]
|
|
Add -mrelax-relocations=no hacks to fix musl build
* this is just a start, dunno if it will work, but I'll just push it out to get feedback (my rust is still building :cry:)
* I don't know much about rustbuild, so i just added that flag in there. it's a total hack, don't judge me
* I suspect the places in the musl .mk files are sufficient (but we may also need it present when building std), I'm not sure, needs more testing.
|
|
core: fix `cargo build` for targets with "max-atomic-width": 0
This crate was failing to compile due to dead_code/unused_imports
warnings. This commits disables these two lints for these targets.
---
r? @alexcrichton
cc @Amanieu is `cfg(target_has_atomic = "8")` the right `cfg` to use? I think that all targets that support some form of atomics will at a minimum support byte level atomics.
FWIW, the only thing that's left in `sync::atomic` for these targets is `Ordering` and the `fence` function.
|
|
Automatically enable -Zorbit if -Zincremental is specified.
Fixes #34973
r? @nikomatsakis
|
|
Apply the same check to function pointer types
|
|
|
|
|
|
|
|
|
|
This crate was failing to compile due to dead_code/unused_imports
warnings. This commits disables these two lints for these targets.
|
|
|
|
|
|
|
|
|
|
resolve: Avoid emitting an unhelpful cascading resolution error
Fixes #35142.
|
|
Escape the unmatched surrogates with lower-case hexadecimal numbers
It's done the same way for the rest of the codepoint escapes.
|
|
Switch to MIR-based translation by default.
This patch makes `-Z orbit` default to "on", which means that by default, functions will be translated from Rust to LLVM IR through the upcoming MIR backend, instead of the antiquated AST backend.
This switch is made possible by the recently merged #33622, #33905 and smaller fixes.
If you experience any issues, please file a report for each of them. You can switch to the old backend to work around problems by either setting `RUSTFLAGS="-Zorbit=off"` or by annotating specific functions with `#[rustc_no_mir]` (which requires `#![feature(rustc_attrs)]` at the crate-level).
I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.
cc @rust-lang/compiler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
implement `From<Vec<char>>` and `From<&'a [char]>` for `String`
Though there are ways to convert a slice or vec of chars into a string,
it would be nice to be able to just do `String::from(&['a', 'b', 'c'])`,
so this PR implements `From<Vec<char>>` and `From<&'a [char]>` for
String.
|
|
|
|
Reimplement TokenStreams using ropes
Title says it all; a reimplementation of TokenStreams as ropes.
r? @nrc
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
- Successful merges: #34802, #35033, #35085, #35114, #35134, #35140, #35141, #35157
- Failed merges:
|
|
Remove CMake workaround
This isn't needed anymore as we aren't using CMake to build compiler-rt since #34873.
|
|
rustc_trans: apply the debug location for the MIR Assert panic call.
Helps `libcore` build with MIR trans and debuginfo; libcore has the body of `panic`, which resulted in:
```
inlinable function call in a function with debug info must have a !dbg location
call void @_ZN4core9panicking5panic17h585bd70cda921012E({ %str_slice, %str_slice, i32 }* @panic_loc12745)
LLVM ERROR: Broken function found, compilation aborted!
```
|
|
r=alexcrichton
tcp-stress-test: Pull out thread count as a constant
This PR factors out the number of concurrent threads used in `tcp-stress-test.rs` to a constant at the top of the file.
We at @NixOS had to lower our thread count as the chrooted-builds don't allow that many threads.
This change will make it easier to lower/increase the count in the future (I actually forgot to change the second `1000` when I was working on this). Another benefit is the removal of magic numbers in the test suite.
This is related to https://github.com/rust-lang/rust/issues/35107
|
|
Rewrite `slice::chunks` doc example to not require printing.
None
|
|
Move caching of inlined HIR into CrateStore
So far we've had separate HIR-inlining caches for each codegen unit and the caching for things inlined during constant evaluation had some holes. Consequently, things would be inlined multiple times if they were used from different codegen units, etc, leading to
- wasted memory,
- multiple `NodeId`s per `DefId` and,
- for things inlined during constant evaluation, no way to map a `NodeId` back to it's original `DefId`.
This PR moves all caching into the CrateStore, solving all of the above problems. It also fixes some bugs in the inlining code, like cyclic in the parent-chains in the HIR map and some `NodeId`'s being translated to more or less random values. There are assertions in place now that should prevent this kind of thing in the future.
This PR based on top of #35090, which contains some necessary fixes.
|
|
Use "x86-64" as the target CPU for NetBSD and Bitrig on amd64.
Using "generic" disables a number of features that are present on all
x86_64 cpus, the "x86-64" target cpu is the common denominator for that
arch.
Refs #20777
|
|
Methods `Fn(Mut,Once)::call(mut,once)` are gated with two feature gates, remove one of them
Methods `Fn::call`, `FnMut::call_mut` and `FnOnce::call_once` are gated with usual library feature `fn_traits` and also hardcoded in the compiler and gated once more with feature `unboxed_closures`
This patch removes the `unboxed_closures`feature gate from these methods (`unboxed_closures` is still used for other things though), now they are gated only with `fn_traits`.
All unnecessary `#![feature(unboxed_closures)]`s are removed, many of them are old and were already unnecessary before the change this PR does.
|
|
LLVM upgrade
As discussed in https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154/46 I'm trying to update the used LLVM checkout in Rust.
I basically took @shepmaster's code and applied it on top (though I did the commits manually, the [original commits have better descriptions](https://github.com/rust-lang/rust/compare/master...avr-rust:avr-support).
With these changes I was able to build rustc. `make check` throws one last error on `run-pass/issue-28950.rs`. Output: https://gist.github.com/badboy/bcdd3bbde260860b6159aa49070a9052
I took the metadata changes as is and they seem to work, though it now uses the module in another step. I'm not sure if this is the best and correct way.
Things to do:
* [x] ~~Make `run-pass/issue-28950.rs` pass~~ unrelated
* [x] Find out how the `PositionIndependentExecutable` setting is now used
* [x] Is the `llvm::legacy` still the right way to do these things?
cc @brson @alexcrichton
|
|
|
