Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Rollup of 3 pull requests #63726

Closed
wants to merge 16 commits into from
Closed

Rollup of 3 pull requests #63726

wants to merge 16 commits into from

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Aug 20, 2019

Successful merges:

Failed merges:

r? @ghost

RalfJung and others added 16 commits August 19, 2019 18:55
@RalfJung @eddyb
start cleaning up subst mess
d4196a7 
fix an ICE

fix method name
@eddyb
rustc_mir: remove wrong calls to subst_from_frame_and_normalize_erasi…
b4f217e 
…ng_regions.
@eddyb
rustc_mir: make subst_from_frame_and_normalize_erasing_regions infall…
ada6f1c 
…ible.
@eddyb
rustc_mir: use self.resolve instead of Instance::resolve where possible.
0919f7c
@eddyb
rustc_mir: add missing subst_from_frame_and_normalize_erasing_regions…
4149964 
… calls.
@eddyb
rustc_mir: disallow non-monomorphic vtables.
ceabe0d
@eddyb
rustc_mir: disallow non-monomorphic reifications.
7d9af83
@eddyb
rustc_typeck: fix the generics for (const-generic) N expression in …
f4aa00b 
…e.g. `[T; N]`.
@eddyb
test: add test from rust-lang#61041.
cb66500
@eddyb
test: add test for rust-lang#61432.
96fc989
@matklad
remove composite tokens support from the lexer
8b932df
@matklad
glue tokens when building token stream
914e1f4
@alexcrichton
bootstrap: Merge the libtest build step with libstd
72470e3 
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.

Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.

After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.

This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
@Centril
Rollup merge of rust-lang#63497 - eddyb:miri-subst, r=oli-obk
5ae0710 
rustc_mir: fix miri substitution/"universe" discipline.

Alternative to rust-lang#61041, based on @RalfJung's own attempt at it.
I haven't done a full audit, but I believe everything is fixed now.

Fixes rust-lang#61432.
Closes rust-lang#61336, as a drive-by fix (for a subset of rust-lang#43408, that is already special-cased).

r? @oli-obk / @RalfJung cc @varkor @yodaldevoid
@Centril
Rollup merge of rust-lang#63637 - alexcrichton:remove-libtest-step, r…
ea88adc 
…=Mark-Simulacrum

bootstrap: Merge the libtest build step with libstd

Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.

Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.

After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.

This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
@Centril
Rollup merge of rust-lang#63709 - matklad:decomposed-tokens, r=petroc…
f01858b 
…henkov

Move token gluing to token stream parsing

work towards rust-lang#63689, this moves token gluing from the lexer to the token tree layer. This is only a minimal step, but I like the negative diff here.

r? @petrochenkov
@Centril
Copy link
Contributor Author

Centril commented Aug 20, 2019

@bors r+ p=3 rollup=never

@bors
Copy link
Contributor

bors commented Aug 20, 2019

📌 Commit f01858b has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 20, 2019
@bors
Copy link
Contributor

bors commented Aug 20, 2019

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout rollup-jufg52c (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self rollup-jufg52c --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message 
warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 20, 2019
@matklad
Copy link
Member

matklad commented Aug 20, 2019

@Centril #63637 has rollup=never, so it probably shounnd't be rolled up:

#63637 (comment)

@Centril Centril closed this Aug 20, 2019
@Centril Centril deleted the rollup-jufg52c branch August 20, 2019 11:25
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@Centril @bors @matklad @RalfJung @eddyb @alexcrichton