| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
fix to last commit
|
|
Reason: Due to changes in bounds of `TryFrom` from `From` to `Into`
|
|
This was intended to land way back in 1.24, but it was backed out due to
breakage which has long since been fixed. An unstable `#[unwind]`
attribute can be used to tweak the behavior here, but this is currently
simply switching rustc's internal default to abort-by-default if an
`extern` function panics, making our codegen sound primarily (as
currently you can produce UB with safe code)
Closes #52652
|
|
std: Depend directly on crates.io crates
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
|
fix intra-link resolution spans in block comments
This commit improves the calculation of code spans for intra-doc
resolution failures. All sugared doc comments should now have the
correct spans, including those where the comment is longer than the
docs.
It also fixes an issue where the spans were calculated incorrectly for
certain unsugared doc comments. The diagnostic will now always use the
span of the attributes, as originally intended.
Fixes #55964.
r? @QuietMisdreavus
|
|
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
|
Test with gdb8.2 and add debuginfo printing function call test
As far as I can see, `print function()` is not tested. It is important feature for debugging.
|
|
libtest: Use deterministic HashMap, avoid spawning thread if there is no concurrency
It seems desirable to make a test and bench runner deterministic, which this achieves by using a deterministic hasher. Also, we we only have 1 thread, we don't bother spawning one and just use the main thread.
The motivation for this is to be able to run the test harness in miri, where we can neither access the OS RNG, nor spawn threads.
|
|
|
|
This commit improves the calculation of code spans for intra-doc
resolution failures. All sugared doc comments should now have the
correct spans, including those where the comment is longer than the
docs.
It also fixes an issue where the spans were calculated incorrectly for
certain unsugared doc comments. The diagnostic will now always use the
span of the attributes, as originally intended.
Fixes #55964.
|
|
Add regression test for ICE
Fixes #55846 with a minimal (or as best as I can manage) test case. I tested this against 1.30.0 manually to confirm it crashes.
The issue seemed to have something to do with associated types. It's possible someone with more knowledge can shrink the test case down further, or make it clearer.
|
|
GuillaumeGomez:span-trait-method-invalid-nb-parameters, r=estebank
fix span for invalid number of parameters in trait method
Fixes #56582.
|
|
emit error with span for empty asserts
Fixes #55547.
|
|
|
|
|
|
|
|
|
|
|
|
Encode `TraitAlias` as if they were `Trait`
Fix #56539.
|
|
|
|
resolve: Reduce some clutter in import ambiguity errors
Noticed in https://www.reddit.com/r/rust/comments/a3pyrw/announcing_rust_131_and_rust_2018/eb8alhi/.
The first error is distracting, but unnecessary, it's a *consequence* of the ambiguity error and appears because one of the ambiguous `actix` modules (unsurprisingly) doesn't have the expected name in it.
|
|
Suggest an appropriate token when encountering `pub Ident<'a>`
Fix #55403. Follow up to #45997.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use a function to access the Hir map to be able to turn it into a query later
r? @eddyb
|
|
Fix ICE with generators and NLL
Fix #55850.
This PR stops an ICE in #55850 by not panicking when a region cannot be named. However, this PR does not (yet) fix the underlying issue that the correct name for the test case provided for the issue (in this instance, `'a`) was not found.
This PR also lays a little bit of groundwork by categorizing yields separately from returns so that region naming can be specialized for this case.
r? @pnkfelix
|
|
codegen_utils, driver: fix clippy errors
- remove a superfluous conversion
- remove an explicit `return`
- rename `MetadataOnlyCodegenBackend::new` to `::boxed`
- single-arm `match` > `if let`
|
|
This commit puts a fix in place for the ICE in region naming code so
that it doesn't break the compiler. However, this results in the
diagnostic being poorer as the borrow explanation that was causing the
ICE is not being added - this should be fixed as a follow-up.
|
|
Unsupport `#[derive(Trait)]` sugar for `#[derive_Trait]` legacy plugin attributes
This is a long deprecated unstable feature that doesn't mesh well with regular resolution/expansion.
How to fix broken code:
- The recommended way is to migrate to stable procedural macros - derives or attributes (https://doc.rust-lang.org/nightly/book/first-edition/procedural-macros.html).
- If that's not possible right now for some reason, you can keep code working with a simple mechanical replacement `#[derive(Legacy)]` -> `#[derive_Legacy]`.
Closes https://github.com/rust-lang/rust/issues/29644
r? @ghost
|
|
attributes
|
|
Ensure that Rustdoc discovers all necessary auto trait bounds
Fixes #50159
This commit makes several improvements to AutoTraitFinder:
* Call infcx.resolve_type_vars_if_possible before processing new
predicates. This ensures that we eliminate inference variables wherever
possible.
* Process all nested obligations we get from a vtable, not just ones
with depth=1.
* The 'depth=1' check was a hack to work around issues processing
certain predicates. The other changes in this commit allow us to
properly process all predicates that we encounter, so the check is no
longer necessary,
* Ensure that we only display predicates *without* inference variables
to the user, and only attempt to unify predicates that *have* an
inference variable as their type.
Additionally, the internal helper method is_of_param now operates
directly on a type, rather than taking a Substs. This allows us to use
the 'self_ty' method, rather than directly dealing with Substs.
|
|
|
|
Fix #56237: normalize type before deferred sizedness checking.
This seems to fix #56237, which was introduced by #56045. I don't thoroughly understand how this works, but the problem seemed to be a lack of normalization.
r? @cramertj
|
|
|
|
Delay gensym creation for "underscore items" (`use foo as _`/`const _`) until name resolution
So they cannot be cloned by macros. See https://github.com/rust-lang/rust/pull/56303 for the discussion.
Mostly fix cross-crate use of underscore items by inverting the "gensyms are lost in metadata" bug as described in https://github.com/rust-lang/rust/pull/56303#issuecomment-442464695.
Fix unused import warnings for single-segment imports (first commit) and `use crate_name as _` imports (as specified in https://github.com/rust-lang/rust/pull/56303#issuecomment-442274118).
Prohibit accidentally implemented `static _: TYPE = EXPR;` (cc https://github.com/rust-lang/rust/pull/55983).
Add more tests for `use foo as _` imports.
|
|
Rollup of 11 pull requests
Successful merges:
- #56315 (Rustdoc inline macro reexport)
- #56332 ([rustdoc] Specific crate search)
- #56362 (Stabilise exhaustive integer patterns)
- #56426 (libsyntax_pos: A few tweaks)
- #56441 (rustbuild: Fix issues with compiler docs)
- #56446 (pass the parameter environment to `traits::find_associated_item`)
- #56500 (cleanup: remove static lifetimes from consts)
- #56525 (Avoid extra copy and syscall in std::env::current_exe)
- #56528 (Remove unused dependency (rustc_lint -> rustc_mir))
- #56548 (Optimized string FromIterator + Extend impls)
- #56553 (Don't print the profiling summary to stdout when -Zprofile-json is set)
Failed merges:
r? @ghost
|
|
Allow calling `const unsafe fn` in `const fn` behind a feature gate
cc #55607
r? @Centril
|
|
pass the parameter environment to `traits::find_associated_item`
dropping the param-env on the floor is obviously the wrong thing to do.
The ICE was probably exposed by #54490 adding the problem-exposing use of
`traits::find_associated_item`.
Fixes #55380.
r? @nikomatsakis
|
|
libsyntax_pos: A few tweaks
|
|
r=nikomatsakis
Stabilise exhaustive integer patterns
This is dependent on the FCP for https://github.com/rust-lang/rfcs/pull/2591 being completed, but that should happen tomorrow, so there's little harm in opening this PR early.
Closes #50907.
|
|
[rustdoc] Specific crate search
Reopening of #54706.
Fixes #54616.
<img width="1440" alt="screenshot 2018-11-29 at 01 29 11" src="https://user-images.githubusercontent.com/3050060/49191372-979adf80-f376-11e8-963e-e4feb927c1da.png">
r? @QuietMisdreavus
|
|
r=QuietMisdreavus
Rustdoc inline macro reexport
Fixes #56173
I assume this needs to have tests? Any pointers where these need to be added?
|
|
r=michaelwoerister
53956 panic on include bytes of own file
fix #53956
When using `include_bytes!` on a source file in the project, compiler would panic on subsequent compilations because `expand_include_bytes` would overwrite files in the source_map with no source. This PR changes `expand_include_bytes` to check source_map and use the already existing src, if any.
|
|
Rollup of 15 pull requests
Successful merges:
- #51753 (Document `From` implementations)
- #55563 (Improve no result found sentence in doc search)
- #55987 (Add Weak.ptr_eq)
- #56119 (Utilize `?` instead of `return None`.)
- #56372 (Refer to the second borrow as the "second borrow" in E0501.rs)
- #56388 (More MIR borrow check cleanup)
- #56424 (Mention raw-ident syntax)
- #56452 (Remove redundant clones)
- #56456 (Handle existential types in dead code analysis)
- #56466 (data_structures: remove tuple_slice)
- #56476 (Fix invalid line number match)
- #56497 (cleanup: remove static lifetimes from consts in libstd)
- #56498 (Fix line numbers display)
- #56523 (Added a bare-bones eslint config (removing jslint))
- #56538 (Use inner iterator may_have_side_effect for Cloned)
Failed merges:
r? @ghost
|
|
Handle existential types in dead code analysis
fixes #55124
r? @cramertj
|
