[DO NOT MERGE] Apply Rust patches on release/8.x #1

This is needed for `-C target-cpu=help` and `-C target-feature=help` in rustc

If this lines are present then we apparently get errors [1] when compiling in the current [2] dist-i686-linux container. Attempts to upgrade both gcc and binutils did not fix the error, so it appears that this may just be a bug in the super old glibc we're using on the dist-i686-linux container. We don't actually need this code anyway, so just work around these issues by removing references to the `*64` functions. This'll get things compiling locally and shouldn't be a regression in functionality. [1]: https://travis-ci.org/rust-lang/rust/jobs/257578199 [2]: https://github.com/rust-lang/rust/tree/eba9d7f08ce5c90549ee52337aca0010ad566f0d/src/ci/docker/dist-i686-linux

For whatever reason this is failing the i686-freebsd builder in the Rust repo as-of this red-hot moment. The build seems to work fine without it so let's just remove it for now and pray there's a better fix later. Although if you're reading this and know of a better fix, we'd love to remove this!

Apparently glibc is so old it doesn't have the _POSIX_ARG_MAX constant. This shouldn't affect anything we use anyway though. https://travis-ci.org/rust-lang/rust/jobs/399333071

Can't seem to figure out how to do this without this patch...

This adds Rust support to Mangled. I am not completely certain that this is needed (or alternatively that it does enough, maybe Mangled::GuessLanguage needs a Rust case). This should be checked before attempting to upstream.

This was needed for the Rust plugin

Add a TypeAndOrName constructor that was declared but not defined. This is used in the Rust plugin. See https://reviews.llvm.org/D44752

Introduce LLDB_PY_LIB_SUFFIX and use it in various places in the build. This lets the x.py-based build work properly without having to set LLVM_LIBDIR_SUFFIX. See https://bugs.llvm.org/show_bug.cgi?id=18957 for some discussion.

Sometimes the DWARF can omit information about a discriminant, for example when an Option shares a discriminant slot with an enum that it wraps. In this case, lldb could crash, because the discriminant was not found and because there was no default variant. No test case because this relies on a compiler bug that will soon be fixed. Fixes llvm#16

While rebasing to master, I missed a spot where an include file was moved. I believe my local build was picking up an installed copy of the header, causing it to succeed locally.

This adds "rust-enabled" to the --version output, so it's easier to tell if lldb has rust support.

This fixes a couple of problems noticed while debugging the rust compiler change to use DW_TAG_variant_part: * IterableDIEChildren returned one extra DIE, because it did not preserve the CU in end() * The entire block dealing with DW_TAG_variant_part was erroneously inside the DW_TAG_member case.

This gives numeric names to tuple fields, because lldb clients expect fields to have names, and because using plain numbers seemed most rust-like. Closes llvm#21

When the discriminant is removed from an enum's members, be sure to rename the fields of any tuple type. This fixes a bug introduced in yesterday's patch.

Prepend an underscore to field names when emitting a C structure, to ensure that tuple fields have valid names.

Remove the by-name cache from RustASTContext. This was not needed and could interact badly with the DWARF parser. Closes llvm#22

This disables aaan enum type name test that is failing with git master rustc. See llvm#24.

Read DW_TAG_template_type_parameter and apply to structure types.

Read DW_TAG_template_type_parameter and apply to function types. Closes llvm#5

The rebase onto a later git master lldb required a change to RustASTContext.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DO NOT MERGE] Apply Rust patches on release/8.x #1

[DO NOT MERGE] Apply Rust patches on release/8.x #1

Commits on Jan 16, 2019