| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
There are multiple issues with them as designed and implemented.
cc #27364
Conflicts:
src/libsyntax/feature_gate.rs
src/test/auxiliary/xcrate_associated_type_defaults.rs
|
|
bound that is likely to change. In that case, it will change to 'static,
so then scan down the graph to see whether there are any hard
constraints that would prevent 'static from being a valid value
here. Report a warning.
|
|
|
|
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
* The `LoopVectorize` option of the LLVM optimization passes has been disabled
as it causes a divide-by-zero exception to happen in LLVM for zero-sized
types. This is reported as https://llvm.org/bugs/show_bug.cgi?id=23763
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
|
|
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
|
|
|
|
Use camel-case naming, and use names which actually make sense in modern Rust.
|
|
|
|
|
|
|
|
|
|
Fixes #24575
Fixes #25673
r? @alexcrichton
|
|
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Closes #18913
|
|
Fixes #24575
|
|
This lets plugin authors opt attributes out of the `custom_attribute`
and `unused_attribute` checks.
cc @thepowersgang
|
|
|
|
|
|
Stripping unconfigured items prior to collecting crate metadata means we
can say things like `#![cfg_attr(foo, crate_type="lib")]`.
Fixes #25347.
|
|
Stripping unconfigured items prior to collecting crate metadata means we
can say things like `#![cfg_attr(foo, crate_type="lib")]`.
Fixes #25347.
|
|
We don't have any pending snapshot-requiring changes. Tests which
continue to be ignored are those that are broken by codegen changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This syntax was removed in b24a3b8 but references remained in the
grammar, the reference, rustdoc generation, and some auxiliary test
files that don't seem to have been used since 812637e.
|
|
|
|
|
|
Closes #19163.
|
|
|
|
|
|
|
|
|
|
metdata: Fix zero-normalization of the pos of a `MultiByteChar`
Fix #24687
The source byte/character mappings for every crate track the collection of multi-characters from its source files specially. When we import the source information for another file into the current compilation unit, we assign its byte-positions unique values by shifting them all by a fixed adjustment, tracked in the `start_pos` field. But when we pull out the source span information for one function from one crate and into our own crate, we need to re-normalize the byte positions: subtracting the old `start_pos` and adding the new `start_pos`. The `new_imported_filemap(..)` method handles adding the new `start_pos`, so all `creader` needs to do is re-normalize each `pos` to zero.
It seems like it was indeed trying to do this, but it mistakenly added the old `start_pos` instead of subtracting it.
|
|
use visible characters for the multibyte character filler.
|
|
There are still quite a few ignored Android tests kicking around, most of which were added in 445faca8441aae34c91318b6ad9e2049885af8dc, which has a pretty unfortunate commit message.
r? @alexcrichton
|
|
|
|
|
|
|
|
Closes #17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
|
|
Such things no longer exist.
|
|
|
|
Conflicts:
src/librustc/plugin/registry.rs
src/libsyntax/ext/base.rs
src/libsyntax/ext/cfg_attr.rs
src/libsyntax/ext/deriving/mod.rs
src/libsyntax/ext/expand.rs
src/libsyntax/print/pprust.rs
src/test/auxiliary/macro_crate_test.rs
|
|
|
|
consts.
|
|
Conflicts:
src/libcore/result.rs
|
|
|
|
|
