| Age | Commit message (Collapse) | Author | Lines |
|---|
|
* Hand rebased from Niels original work on 1.9.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gdb: Fix pretty-printing special-cased Rust types
gdb trunk now reports fully qualified type names, just like lldb. Move lldb code for extracting unqualified names to shared file.
For current releases of gdb, `extract_type_name` should just be a no-op.
Fixes #35155
|
|
Make version check in gdb_rust_pretty_printing.py more compatible.
Some versions of Python don't support the `major` field on the object returned by `sys.version_info`.
Fixes #35724
r? @brson
|
|
|
|
Some versions of Python don't support the `major` field on the
object returned by `sys.version_info`.
|
|
gdb trunk now reports fully qualified type names, just like lldb. Move
lldb code for extracting unqualified names to shared file.
|
|
Rollup of 8 pull requests
- Successful merges: #34802, #35033, #35085, #35114, #35134, #35140, #35141, #35157
- Failed merges:
|
|
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
|
|
|
|
This was needed at least when local rust was 1.9.0 on darwin.
Fixes #35149
|
|
Now it prints full paths on MSVC, but we're only interested in path names
|
|
Use the same procedure as Python to determine whether a character is
printable, described in [PEP 3138]. In particular, this means that the
following character classes are escaped:
- Cc (Other, Control)
- Cf (Other, Format)
- Cs (Other, Surrogate), even though they can't appear in Rust strings
- Co (Other, Private Use)
- Cn (Other, Not Assigned)
- Zl (Separator, Line)
- Zp (Separator, Paragraph)
- Zs (Separator, Space), except for the ASCII space `' '` (`0x20`)
This allows for user-friendly inspection of strings that are not
English (e.g. compare `"\u{e9}\u{e8}\u{ea}"` to `"éèê"`).
Fixes #34318.
[PEP 3138]: https://www.python.org/dev/peps/pep-3138/
|
|
If local-rust is the same as the current version, then force a local-rebuild
In Debian, we would like the option to build/rebuild the current release from
*either* the current or previous stable release. So we use enable-local-rust
instead of enable-local-rebuild, and read the bootstrap key dynamically from
whatever is installed locally.
In general, it does not make much sense to allow enable-local-rust without also
setting the bootstrap key, since the build would fail otherwise.
(The way I detect "the bootstrap key of [the local] rustc installation" is a bit hacky, suggestions welcome.)
|
|
|
|
Update Unicode tables to 9.0
I just updated `unicode.py`'s generated copyright year, then ran it.
|
|
First attempt to fix nightlies
This is just https://github.com/rust-lang/rust/pull/34669 but I added some comments so it can land.
|
|
Just mention there are differences between python versions
|
|
|
|
Avoid redundant downloads when bootstrapping
If the local file is available, then verify it against the hash we just
downloaded, and if it matches then we don't need to download it again.
|
|
|
|
r=alexcrichton
Add x86 intrinsics for bit manipulation (BMI 1.0, BMI 2.0, and TBM).
This PR adds the LLVM x86 intrinsics for the bit manipulation instruction sets (BMI 1.0, BMI 2.0, and TBM).
The objective of this pull-request is to allow building a library that implements all the algorithms offered by those instruction sets, using compiler intrinsics for the targets that support them (by means of `target_feature`).
The target features added are:
- `bmi`: Bit Manipulation Instruction Set 1.0, available in Intel >= Haswell and AMD's >= Jaguar/Piledriver,
- `bmi2`: Bit Manipulation Instruction Set 2.0, available in Intel >= Haswell and AMD's >= Excavator,
- `tbm`: Trailing Bit Manipulation, available only in AMD's Piledriver (won't be available in newer CPUs).
The intrinsics added are:
- BMI 1.0:
- `bextr`: Bit field extract (with register).
- BMI 2.0:
- `bzhi`: Zero high bits starting with specified bit position.
- `pdep`: Parallel bits deposit.
- `pext`: Parallel bits extract.
- TBM:
- `bextri`: Bit field extract (with immediate).
|
|
Make rust-lldb warn about unsupported versions of LLDB
r? @alexcrichton
|
|
|
|
Use lazy iterator in vec/slice gdb pretty printers
|
|
|
|
If the local file is available, then verify it against the hash we just
downloaded, and if it matches then we don't need to download it again.
|
|
|
|
|
|
Convert makefiles to build LLVM/compiler-rt with CMake
This is certainly buggy, but I have successfully built on x86_64-unknown-linux-gnu and x86_64-pc-windows-gnu. I haven't built successfully on mac yet, and I've seen mysterious test failures on Linux, but I'm interested in throwing this at the bots to see what they think.
|
|
2.0, and TBM.
|
|
and TBM.
|
|
|
|
|
|
|
|
|
|
|
|
some Python nits and fixes
|
|
This commit prepares the source for a new stage0 compiler, the 1.10.0 beta
compiler. These artifacts are hot off the bots and should be ready to go.
|
|
|
|
Efficient trie lookup for boolean Unicode properties
Replace binary search of ranges with trie lookup using leaves of
64-bit bitmap chunks. Benchmarks suggest this is approximately 10x
faster than the bsearch approach.
|
|
gdb Pretty Print: generic encoded was failing on reference/pointer types
If you debug this program using **gdb**
```rust
fn main() {
let x = 10;
let y = Some(&x);
// additional code
}
```
And you try to print **y**'s value from the debugger, you get the following:
```
(gdb) print y
Python Exception <class 'gdb.error'> Cannot convert value to int.:
$1 = {RUST$ENCODED$ENUM$0$None = Some = {0x7fff5fbff97c}}
```
What happens is that inside **debugger_pretty_printers_common.py** the method `is_null_variant` doesn't have any special handling for pointer values so it ends up calling `.as_integer()` on `discriminant_val` (which holds a pointer) and fails.
Considering it needs to handle pointers and return _true_ when the pointer is _null_, I modified the `.as_integer()` method in **gdb_rust_pretty_printing.py** to take pointers into consideration.
After this modification **gdb** prints **y** like this:
```
(gdb) print y
$1 = Some = {0x7fff5fbff97c}
```
Now, it would be nice to print something useful (instead of a pointer address) but the pretty printer doesn't currently handle references/pointers so that's a completely different subject.
|
|
|
|
When bootstrapping Rust using a previously built toolchain, I noticed
a number of libraries were not copied in. As a result the copied in
rustc fails to execute because it can't find all its dependences.
Add them into the local_stage0.sh script.
|
