Currently ', " and \ are escaped as \', \" and \\ respectively. This
leads to confusing messages such as `error: unknown start of token: \\`
when encountering a single backslash.
Fix by emitting printable ASCII characters directly. This will still
escape \r, \n, \t and Unicode characters.
Fixes#47902
Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads. The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below
that address, if so reporting it as a stack overflow.
Now `unix` targets report a `Range<usize>` representing the guard
memory, so it can cover arbitrary guard sizes. Non-`unix` targets which
always return `None` for guards now do so with `Option<!>`, so they
don't pay any overhead.
For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack. However, there's no simple way for us to
know where the guard page actually lies, so now we declare it as the
whole range of `stackaddr ± guardsize`, and any fault therein will be
called a stack overflow. This fixes#47863.
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!
Avoid underflow in render_source_line
While testing rust-lang/rust#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/rust#46655 has been approved.
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!
rustc_trans: keep LLVM types for trait objects anonymous.
Fixes#47638 by reverting the addition of readable LLVM trait object type names.
r? @nikomatsakis
[MSP430] Don't enable trap_unreachable option by default on msp.
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.
r? @alexcrichton
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.
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.
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_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).
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.
Fix regression: account for trait methods in arg count mismatch error
Fixed#47706 (https://github.com/rust-lang/rust/issues/47706#issuecomment-361161495)
Original PR #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.
is_unsafe_place only filters out statics in the rhs, not the lhs. Since
it's possible to reach that 'Place::Static', we handle statics the same
way as we do locals.
Fixes#47789
We use binaryen's linker to produce a wasm file (via s2wasm). The wasm writer has capabilities to export source maps.
The produced source map contains references to the original file, that might require additional source map file processing to include / package original files with it.
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
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.
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.
