Uh oh!
There was an error while loading. Please reload this page.
Rollup of 16 pull requests - #47900
Merged
Merged
Conversation
While testing rust-lang#47655 I was able to make the compiler panic when it's compiled with debug assertions: ```shell > rustc /dev/null --crate-type proc-macro error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports note: rustc 1.25.0-dev running on x86_64-apple-darwin note: run with `RUST_BACKTRACE=1` for a backtrace thread 'rustc' panicked at 'attempt to subtract with overflow', librustc_errors/emitter.rs:287:49 ``` Without debug assertions the following warning is emitted: ```shell > rustc /dev/null --crate-type proc-macro warning: unused variable: `registrar` --> /dev/null:0:1 | | = note: #[warn(unused_variables)] on by default = note: to avoid this warning, consider using `_registrar` instead ``` The panic is due to the unused variable warning being spanned to `/dev/null:0:1`. When `render_source_line` subtracts 1 from the line number to look up the source line it panics due to underflow. Without debug assertions this would wrap and cause us to return a blank string instead. Fix by explicitly testing for 0 and exiting early. I'm unsure how to automatically test this now that rust-lang#46655 has been approved.
If the original name is uppercase, use camel case. Otherwise, use snake case.
On MIPS, error number 98 is not EADDRINUSE (it is EPROTOTYPE). To fix the resulting test failure this causes, use a more portable error number in the example documentation. EINVAL shold be more reliable because it was defined in the original Unix as 22 so hopefully most derivatives have defined it the same way.
This copies what clang does. There is a long explanation as to why this is needed in the clang source (tools/clang/lib/Basic/Targets/Mips.h).
This is a test of `target_feature`, which needs a rust-specific patch to LLVM to add `MCSubtargetInfo::getFeatureTable()`.
I was testing out the tip support to see what's going on with wasm, and this was I believe the only issue encountered with LLVM 7 support so far.
This commit adds a new option to target specifictions to specify that symbols should be "hidden" visibility by default in LLVM. While there are no existing targets that take advantage of this the `wasm32-unknown-unknown` target will soon start to use this visibility. The LLD linker currently interprets `hidden` as "don't export this from the wasm module" which is what we want for 90% of our functions. While the LLD linker does have a "export this symbol" argument which is what we use for other linkers, it was also somewhat easier to do this change instead which'll involve less arguments flying around. Additionally there's no need for non-`hidden` visibility for most of our symbols! This change should not immediately impact the wasm targets as-is, but rather this is laying the foundations for soon integrating LLD as a linker for wasm code.
Since MSP430 doesn't meaningfully support faulting on illegal instructions, LLVM generates a call to abort() function instead of a trap instruction. Such calls are 4 bytes long, and that is too much overhead for such small target.
…ochenkov use correct casing for rename suggestions If the original name is uppercase, use camel case. Otherwise, use snake case.
Marked Debug implementations for primitive types as #[inline] Change for issue rust-lang#47792.
Fix regression: account for trait methods in arg count mismatch error Fixedrust-lang#47706 (rust-lang#47706 (comment)) Original PR rust-lang#47747 missed methods on trait definitions. This edit was done in GitHub. I think I got the signature of the variant right, going by the ICE debug output and the other cases above.
…dtolnay std: use more portable error number in from_raw_os_error docs On MIPS, error number 98 is not `EADDRINUSE` (it is `EPROTOTYPE`). To fix the resulting test failure this causes, use a more portable error number in the example documentation. `EINVAL` shold be more reliable because it was defined in the original Unix as 22 so hopefully most derivatives have defined it the same way.
rustc_trans: clobber $1 (aka $at) on mips This copies what clang does. There is a long explanation as to why this is needed in the clang source (tools/clang/lib/Basic/Targets/Mips.h).
…or, r=nikomatsakis Update associated constants error message Fixesrust-lang#47570.
Ignore run-pass/sse2 when using system LLVM This is a test of `target_feature`, which needs a rust-specific patch to LLVM to add `MCSubtargetInfo::getFeatureTable()`.
rustc: Add some defines for LLVM 7 compat I was testing out the tip support to see what's going on with wasm, and this was I believe the only issue encountered with LLVM 7 support so far.
…, r=cramertj rustc: Add an option to default hidden visibility This commit adds a new option to target specifictions to specify that symbols should be "hidden" visibility by default in LLVM. While there are no existing targets that take advantage of this the `wasm32-unknown-unknown` target will soon start to use this visibility. The LLD linker currently interprets `hidden` as "don't export this from the wasm module" which is what we want for 90% of our functions. While the LLD linker does have a "export this symbol" argument which is what we use for other linkers, it was also somewhat easier to do this change instead which'll involve less arguments flying around. Additionally there's no need for non-`hidden` visibility for most of our symbols! This change should not immediately impact the wasm targets as-is, but rather this is laying the foundations for soon integrating LLD as a linker for wasm code.
bors
commented
Jan 31, 2018
Collaborator
⌛ Testing commit 2eb04352bf93e990e349e45fc26068c0bdcec3ca with merge 8077b54247313632e74573cbd0ff1ff630860fbe... |
bors
commented
Jan 31, 2018
Collaborator
💔 Test failed - status-appveyor |
MemberAuthor
Hmm what? |
Adding ICH to the glossary. Fixesrust-lang#47782.
kennytm
commented
Jan 31, 2018
MemberAuthor
bors
commented
Jan 31, 2018
Collaborator
📌 Commit 64fc9d2 has been approved by |
bors
commented
Jan 31, 2018
Collaborator
⌛ Testing commit 64fc9d2 with merge dc136553be02e5f20643e9239c2ef98fef252273... |
bors
commented
Jan 31, 2018
Collaborator
💔 Test failed - status-appveyor |
Right now this directory is located under: $sysroot/lib/rustlib/$target/lib/codegen-backends but after seeing what we do in a few other places it seems that a more appropriate location would be: $sysroot/lib/rustlib/$target/codegen-backends so this commit moves it!
MemberAuthor
🤔 I don't see why there would be many timed out jobs. Assuming spurious. |
…source-line, r=estebank Avoid underflow in render_source_line While testing rust-lang#47655 I was able to make the compiler panic when it's compiled with debug assertions: ```shell > rustc /dev/null --crate-type proc-macro error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports note: rustc 1.25.0-dev running on x86_64-apple-darwin note: run with `RUST_BACKTRACE=1` for a backtrace thread 'rustc' panicked at 'attempt to subtract with overflow', librustc_errors/emitter.rs:287:49 ``` Without debug assertions the following warning is emitted: ```shell > rustc /dev/null --crate-type proc-macro warning: unused variable: `registrar` --> /dev/null:0:1 | | = note: #[warn(unused_variables)] on by default = note: to avoid this warning, consider using `_registrar` instead ``` The panic is due to the unused variable warning being spanned to `/dev/null:0:1`. When `render_source_line` subtracts 1 from the line number to look up the source line it panics due to underflow. Without debug assertions this would wrap and cause us to return a blank string instead. Fix by explicitly testing for 0 and exiting early. I'm unsure how to automatically test this now that rust-lang#46655 has been approved.
… r=alexcrichton rustc: Move location of `codegen-backends` dir Right now this directory is located under: ``` $sysroot/lib/rustlib/$target/lib/codegen-backends ``` but after seeing what we do in a few other places it seems that a more appropriate location would be: ``` $sysroot/lib/rustlib/$target/codegen-backends ``` so this commit moves it!
Fix ICE when reading non-UTF-8 input from stdin Fixesrust-lang#22387.
Specialize StepBy::nth This allows optimizations of implementations of the inner iterator's `.nth` method.
bors
commented
Jan 31, 2018
Collaborator
📌 Commit af95302 has been approved by |
bors
commented
Jan 31, 2018
Collaborator
bors added a commit
that referenced
this pull request
Jan 31, 2018
bors
commented
Jan 31, 2018
Collaborator
☀️ Test successful - status-appveyor, status-travis |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
codegen-backendsdir #47893, Fix ICE when reading non-UTF-8 input from stdin #47895, Specialize StepBy::nth #47552