Skip to content

/llvm-project forked from llvm/llvm-project

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 25 commits into from

Conversation

Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
6 participants
@cuviper @nikic @alexcrichton @tromey @bitshifter @nagisa
@cuviper
Copy link
Member

cuviper commented Jan 11, 2019

This PR should not actually be merged, but pushed to a new branch. I can do this once we're happy with the changes, and decide on a branch name. FWIW, upstream is naming their stable branches like release/7.x, so I suggest a rust/ prefix here, and indicating it's pre-8.0 would be nice too.

  • llvm/: All patches applied cleanly, or were already upstream, except 8b036feacf91 from rust-lang/llvm#131. That was a revert which I believe has since been fixed properly by D54997 -- cc @nikic for verification.

  • clang/: Rust has no patches AFAICS.

  • lld/: The one MSVC cmake patch applied fine.

  • lldb/: All patches applied cleanly except for 8e114ffe6b6a, now 40e425a, but I think I resolved that OK. @tromey, are these patches headed upstream?

I haven't actually tested that this works yet, nor integrated it into the rust repo. 😅
@nikic

This comment has been minimized.

Sign in to view
Copy link

nikic commented Jan 11, 2019

llvm/: All patches applied cleanly, or were already upstream, except 8b036feacf91 from rust-lang/llvm#131. That was a revert which I believe has since been fixed properly by D54997 -- cc @nikic for verification.

That's correct, the revert is no longer necessary.
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jan 11, 2019

🎊 thanks @cuviper!

For naming, how about:

  • rustc/pre-8.0-2019-01-11 - used when we're between releases
  • rustc/8.0 - used when we've forked off an actual release

(of course open to any other suggestions)
@nikic

This comment has been minimized.

Sign in to view
Copy link

nikic commented Jan 11, 2019

@alexcrichton I'd go for always using the rustc/8.0-2019-01-11 format. Even if we switch to following a release branch rather than master, we'd likely still want to rebase at some point (to switch to the point release if nothing else).
@cuviper

This comment has been minimized.

Sign in to view
Copy link
Member Author

cuviper commented Jan 11, 2019

@nikic without any kind of pre-release signifier? I guess I'm OK with that if we're including the snapshot date, as opposed to our current opaque v1/v2 branches.
@tromey

This comment has been minimized.

Sign in to view
Copy link

tromey commented Jan 11, 2019

[... lldb patches ...]

are these patches headed upstream?

No, upstream did not want new language plugins, and instead preferred us to fork. I'm not completely sure that the troublesome Python config patch is even needed, it might have only been for Linux.

@cuviper cuviper referenced this pull request Jan 15, 2019

Merged

Cherry-pick a fix for LLVM issue 40289 #135

@cuviper cuviper force-pushed the cuviper:rust branch 3 times, most recently from dc0a10a to 6c099ba Jan 15, 2019

@cuviper

This comment has been minimized.

Sign in to view
Copy link
Member Author

cuviper commented Jan 15, 2019

Status: This branch is working well with my rust llvm-monorepo branch (compare). LLVM is scheduled to create the 8.x branch tomorrow, so I plan to rebase once more on that and then submit a rust PR.

bitshifter and others added some commits Jul 10, 2016

@bitshifter @cuviper
Add accessors for MCSubtargetInfo CPU and Feature tables 
This is needed for `-C target-cpu=help` and `-C target-feature=help` in rustc
865c1f7
@nagisa @cuviper
Add knowledge of __rust_{alloc,realloc,dealloc}
392947a
@alexcrichton @cuviper
Fix compile on dist-i686-linux builder 
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
122c3dc
@alexcrichton @cuviper
Disable checks for libatomic for now 
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!
b73884a
@alexcrichton @cuviper
Compile with /MT on MSVC 
Can't seem to figure out how to do this without this patch...
b1ec4cb
@tromey @cuviper
Add Rust support to Mangled 
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.
1ecf8ed
@tromey @cuviper
Add DIERef::operator== 
This was needed for the Rust plugin
9fa3339
@tromey @cuviper
Add a missing TypeAndOrName constructor 
Add a TypeAndOrName constructor that was declared but not defined.
This is used in the Rust plugin.  See https://reviews.llvm.org/D44752
e6a7452
@tromey @cuviper
Add Rust support to the Python test harness
ea4ac97
@tromey @cuviper
The Rust plugin
df47965
@alexcrichton @cuviper
Fix compile on dist-x86_64-linux builder 
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
bd18bd8
@tromey @cuviper
Compute Python library suffix in CMakeLists.txt 
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.
b8bd5dc
@tromey @cuviper
Do not crash when enum discriminant is not recognized 
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 #16
02ddf76
@tromey @cuviper
Use correct include path for State.h 
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.
0e77fbd
@tromey @cuviper
Add "rust-enabled" to --version output 
This adds "rust-enabled" to the --version output, so it's easier to
tell if lldb has rust support.
0322285
@tromey @cuviper
Fix handling of variant parts 
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.
d957e27
@tromey @cuviper
Give names to tuple fields 
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 #21
463cd70
@tromey @cuviper
Rename tuple fields after discriminant is removed 
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.
945de34
@tromey @cuviper
Fix field names when emitting a C structure 
Prepend an underscore to field names when emitting a C structure, to
ensure that tuple fields have valid names.
ff0a15a
@tromey @cuviper
Remove by-name cache from RustASTContext 
Remove the by-name cache from RustASTContext.  This was not needed and
could interact badly with the DWARF parser.  Closes #22
28e0138

tromey and others added some commits Nov 14, 2018

@tromey @cuviper
Disable enum type test 
This disables aaan enum type name test that is failing with git master
rustc.  See #24.
af32307
@tromey @cuviper
Read template parameters for structure types 
Read DW_TAG_template_type_parameter and apply to structure types.
2ed5e5d
@tromey @cuviper
Read template parameters for function types 
Read DW_TAG_template_type_parameter and apply to function types.

Closes #5
8027847
@tromey @cuviper
Fix the build after the rebase 
The rebase onto a later git master lldb required a change to
RustASTContext.
0fb81ce
@cuviper
Fix DWARFASTParserRust::ParseFunctionFromDWARF for r350943
a27fbee

@cuviper cuviper force-pushed the cuviper:rust branch from 6c099ba to a27fbee Jan 16, 2019

@cuviper cuviper changed the base branch from master to release/8.x Jan 16, 2019

@cuviper cuviper changed the title [DO NOT MERGE] Apply Rust patches on master [DO NOT MERGE] Apply Rust patches on release/8.x Jan 16, 2019

@cuviper

This comment has been minimized.

Sign in to view
Copy link
Member Author

cuviper commented Jan 16, 2019

This is pushed to rustc/8.0-2019-01-16, and the PR is rust-lang/rust#57675.

@cuviper cuviper closed this Jan 16, 2019

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jan 16, 2019

Thanks so much @cuviper!

@cuviper cuviper deleted the cuviper:rust branch Jan 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.