- 20 8月, 2020 7 次提交
-
-
由 Lzu Tao 提交于
-
由 Lzu Tao 提交于
-
由 Lzu Tao 提交于
-
由 Eric Huss 提交于
-
由 Eric Huss 提交于
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
- 19 8月, 2020 16 次提交
-
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Rich Kadel 提交于
-
由 Bastian Kauschke 提交于
-
由 Bastian Kauschke 提交于
-
由 Bastian Kauschke 提交于
-
由 Tomasz Miąsko 提交于
cmake-rs@8141f0e changed the logic for handling asm compiler flags. This change was pulled in with the cmake 0.1.42 -> 0.1.44 update. This introduced two new flags to the LLVM build, breaking it: "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" This patch should resolve the breakage by handling it in bootstrap.
-
由 Tyson Nottingham 提交于
Avoid showing this error where it doesn't make sense by not assuming "and" and "or" were intended to mean "&&" and "||" until after we decide to continue parsing input as an associative expression. Note that the decision of whether or not to continue parsing input as an associative expression doesn't actually depend on this assumption. Fixes #75599
-
由 Josh Stone 提交于
-
- 18 8月, 2020 17 次提交
-
-
由 Jubilee Young 提交于
Per https://github.com/rust-lang/rust/pull/75555#issuecomment-675090858 Zlib license might be OK. "OR Apache-2.0 OR MIT" definitely is. unicode-normalization depends on this and rustc_parse, clippy, and many other things depend on unicode-normalization.
-
由 Mark Rousskov 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Aleksey Kladov 提交于
treeify depends on an outdated version of clap, which will fail to compile when we promote missing_fragment_specifier future compat lint to error (ie, old clap contains code that shouldn't have compiled in the first place). Additionally, this crate seem tiny relative to other crates we are testing here, so it seems like it doesn't provide that much additional confidence. The same happens with tokei project, but it is an actively maintained one, so we can just upgrade it to a version from 2018, where clap was upgraded.
-
由 Ralf Jung 提交于
-
由 Igor Matuszewski 提交于
-
由 Ralf Jung 提交于
-
由 Aleksey Kladov 提交于
-
由 Aleksey Kladov 提交于
It has been deny_by_default since 2017 (and warned for some time before that), so it seems reasonable to promote it. The specific technical motivation to do this now is to remove a field from `ParseSess` -- it is a global state, and global state makes extracting libraries annoying. Closes #40107
-
由 Aleksey Kladov 提交于
-
由 Joshua Nelson 提交于
-
由 Austin Lasher 提交于
-
由 Austin Lasher 提交于
-
由 Ujjwal Sharma 提交于
-
由 Dan Cross 提交于
Make sure to test for file types against the non-canonicalized name to avoid detecting the wrong type. Some systems save build artifacts into associative file stores that do not preserve extensions, and then link to those using conventionally-named symbolic links that are the arguments to `rustc` et al. If we canonicalize before testing the type, we resolve the symlink, the extension is lost and we might treat rlibs and rmetas as dylibs. The fix is to introduce a temporary to hold the canonicalized name, compare against the non-canonical name, and add a comment explaining what's going on for the would-be maintainer who sees a potential cleanup. Signed-off-by: NDan Cross <dcross@google.com>
-
由 Cameron Taggart 提交于
-