jiebi/CodeConvo huggingface dataset:
Change:
code: This causes a very confusing error message First, the message talks about "enum variant", does it mean ? Second, I don't get why it does not compile anyway. If I rename it builds, but why can't it figure out that that a var and function are different things even if they have the same name? Fun fact: this doesn't build either but this does: Shouldn't the 2 snippets behave identical?
They are not because on the second case the local binding doesn't exist yet, so the mod level function is not yet shadowed. In the other case, the function has been shadowed by the local binding, so it fails to compile. No, it's just confused thinking that is . The error message should mention the shadowing of the function.
Just ran into this again with a more simple case :( IMO this should compile because we know that is of type and not so querying the variable is the only thing that makes sense here..? The error message is not really helping imo I wonder if type ascription could solve this:

Discussion:
); } <ins> if let hir::ExprKind::Path(hir::QPath::Resolved(None, path)) = callee_expr.kind && let Res::Local(_) = path.res && let [segment] = &path.segments[..] { for id in self.tcx.hir().items() { if let Some(node) = self.tcx.hir().get_if_local(id.owner_id.into()) && let hir::Node::Item(item) = node && let hir::ItemKind::Fn(..) = item.kind && item.ident.name == segment.ident.name { err.span_label( self.tcx.def_span(id.owner_id), "this function of the same name is available here, but it's shadowed by  the local binding", ); } } } </ins> let mut inner_callee_path = None; let def = match callee_expr.kind { hir::ExprKind::Path(ref qpath) => {

|             ^^^------- |             | |             call expression requires function <ins> ... LL | fn foo(file: &str) -> bool { | -------------------------- this function of the same name is available here, but it's shadowed by the local binding </ins> error: aborting due to previous error
Change:
The output of a test suite starting when using the json formatter represents "test_count" as a json string, like so: I would expect it to be a number like this:
It also seems like "filtered_out" on run finish is also unexectedly a string.

Discussion:
impl<T: Write> OutputFormatter for JsonFormatter<T> { fn write_run_start(&mut self, test_count: usize) -> io::Result<()> { self.write_message(&*format!( <del> r#"{{ "type": "suite", "event": "started", "test_count": "{}" }}"#, </del> <ins> r#"{{ "type": "suite", "event": "started", "test_count": {} }}"#, </ins> test_count )) }

"allowed_fail": {},  "ignored": {},  "measured": {},  <del> "filtered_out": "{}" }}", </del> <ins> "filtered_out": {} }}", </ins> if state.failed == 0 { "ok" } else { "failed" }, state.passed, state.failed + state.allowed_fail,

<del> { "type": "suite", "event": "started", "test_count": "4" } </del> <ins> { "type": "suite", "event": "started", "test_count": 4 } </ins> { "type": "test", "event": "started", "name": "a" } { "type": "test", "name": "a", "event": "ok" } { "type": "test", "event": "started", "name": "b" }

{ "type": "test", "name": "c", "event": "ok" } { "type": "test", "event": "started", "name": "d" } { "type": "test", "name": "d", "event": "ignored" } <del> { "type": "suite", "event": "failed", "passed": 2, "failed": 1, "allowed_fail": 0, "ignored": 1, "measured": 0, "filtered_out": "0" } </del> <ins> { "type": "suite", "event": "failed", "passed": 2, "failed": 1, "allowed_fail": 0, "ignored": 1, "measured": 0, "filtered_out": 0 } </ins>
Change:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.

Discussion:
// definition... // We don't allow argument names to be left off in edition 2018. <del> p.parse_arg_general(p.span.rust_2018()) </del> <ins> p.parse_arg_general(p.span.rust_2018(), true) </ins> })?; generics.where_clause = self.parse_where_clause()?;

/// This version of parse arg doesn't necessarily require /// identifier names. <del> fn parse_arg_general(&mut self, require_name: bool) -> PResult<'a, Arg> { </del> <ins> fn parse_arg_general(&mut self, require_name: bool, is_trait_item: bool) -> PResult<'a, Arg> { </ins> maybe_whole!(self, NtArg, |x| x); if let Ok(Some(_)) = self.parse_self_arg() {

String::from("<identifier>: <type>"), Applicability::HasPlaceholders, ); <ins> } else if require_name && is_trait_item { if let PatKind::Ident(_, ident, _) = pat.node { err.span_suggestion_with_applicability( pat.span, "explicitly ignore parameter", format!("_: {}", ident), Applicability::MachineApplicable, ); } err.note("anonymous parameters are removed in the 2018 edition (see RFC 1685)"); </ins> } return Err(err);

/// Parse a single function argument crate fn parse_arg(&mut self) -> PResult<'a, Arg> { <del> self.parse_arg_general(true) </del> <ins> self.parse_arg_general(true, false) </ins> } /// Parse an argument in a lambda header e.g. |arg, arg|

} } } else { <del> match p.parse_arg_general(named_args) { </del> <ins> match p.parse_arg_general(named_args, false) { </ins> Ok(arg) => Ok(Some(arg)), Err(mut e) => { e.emit();

--> $DIR/anon-params-denied-2018.rs:6:15 | LL |     fn foo(i32); //~ expected one of `:` or `@`, found `)` <del> |               ^ expected one of `:` or `@` here </del> <ins> |            ---^ expected one of `:` or `@` here |            | |            help: explicitly ignore parameter: `_: i32` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) </ins> error: expected one of `:` or `@`, found `,` --> $DIR/anon-params-denied-2018.rs:8:36 | LL |     fn bar_with_default_impl(String, String) {} <del> |                                    ^ expected one of `:` or `@` here </del> <ins> |                              ------^ expected one of `:` or `@` here |                              | |                              help: explicitly ignore parameter: `_: String` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) </ins> error: aborting due to 2 previous errors
Change:
The doc for canonicalize state that the function will return an error if a component in a path is not a directory. Using canonicalize on a path with a file component does not return an error for me, e.g. fs::canonicalize("").unwrap(); works without error. rustc 1.28.0 ( 2018-07-30) binary: rustc commit-hash: commit-date: 2018-07-30 host: x86_64-apple-darwin release: 1.28.0 LLVM version: 6.0

Discussion:
/// limited to just these cases: /// /// * `path` does not exist. <del> /// * A component in path is not a directory. </del> <ins> /// * A non-final component in path is not a directory. </ins> /// /// # Examples ///
Change:
() Errors: Seems like this should work.
The following works: Switching to be of type itself. Adding , and then switching to be of type
Huh, what if you cast it to ? That works, right?
Adding an intermediate cast to does make it work.
So having a projection in the type, blocks the cast from happening? That's a bit weird. cc
The fnsig function on fn item types is returning unnormalized types directly from the tcx. Defined in The relevant call-site is at

Discussion:
match self.expr_ty.kind { ty::FnDef(..) => { // Attempt a coercion to a fn pointer type. <del> let f = self.expr_ty.fn_sig(fcx.tcx); </del> <ins> let f = fcx.normalize_associated_types_in( self.expr.span, &self.expr_ty.fn_sig(fcx.tcx), ); </ins> let res = fcx.try_coerce( self.expr, self.expr_ty,

<ins> // check-pass trait Zoo { type X; } impl Zoo for u16 { type X = usize; } fn foo(abc: <u16 as Zoo>::X) {} fn main() { let x: *const u8 = foo as _; } </ins>
Change:
When I run on (branch refactor-datatypes) I receive an internal compiler error. Everything works fine on stable (). Also everything works if I remove the links in the doc comments. : Backtrace:
I removed the links in the latest commits so I can document on nightly. The latest commit that still contains the links is: Lythenas/rust-orgmode
I experimented a little more and found the following: When I have a doc comment with one link everything works: Also when specifying the link target it works: When there is more than one link in one doc comment the compiler panics: Even when one of them has a link target: But it works when both links have a target: Also this does not happen in the main crate only in the sub-crate. I followed the proc macro guide in the book and created a subfolder named "rust-orgmode-derive. And in the of the main crate I to the dependencies.
I just tried to document that commit you linked with , and it did not give the same ICE. It looks like this issue has been fixed?
With the above commit I still get the same error using .
I'm afraid i'm not seeing it. Is this the right commit?
Aha! I looked again and it turns out i'm documenting the wrong crate. It looks like fixes this issue as well!
Sorry I forgot to mention that you have to swap two lines to get it to compile. Because now you have to put attributes before derive, which was not the case when I wrote this. But thanks for fixing this :+1:

Discussion:
let parent_scope = resolver.dummy_parent_scope(); if let Ok(def) = resolver.resolve_macro_to_def_inner(&path, MacroKind::Bang, &parent_scope, false, false) { <del> if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) { return Some(def); </del> <ins> if let Def::Macro(_, MacroKind::ProcMacroStub) = def { // skip proc-macro stubs, they'll cause `get_macro` to crash } else { if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) { return Some(def); } </ins> } } if let Some(def) = resolver.all_macros.get(&Symbol::intern(path_str)) {

#![crate_type="proc-macro"] #![crate_name="some_macros"] <ins> // @has some_macros/index.html // @has - '//a/[@href="attr.some_proc_attr.html"]' 'some_proc_attr' //! include a link to [some_proc_attr] to make sure it works. </ins> extern crate proc_macro; use proc_macro::TokenStream;
Change:
I can't be sure that this behavior is unintended, but it definitely seems very strange and undesirable to me. This code works fine: But change the order of the trait bounds in the associated type , and it fails:
Probably a duplicate of
Here is another case of such behavior (). However, this will compile: Also, an example with concrete types will compile too: Similar issues:
This is fixed on nightly. Presumably by
I just bisected, and indeed this was fixed by . I think this needs a test, and then it can be closed.

Discussion:
<ins> // check-pass // From https://github.com/rust-lang/rust/issues/54121/ // // Whether the code compiled depended on the order of the trait bounds in // `type T: Tr<u8, u8> + Tr<u16, u16>` // But both should compile as order shouldn't matter. trait Tr<A, B> { fn exec(a: A, b: B); } trait P { // This compiled successfully type T: Tr<u16, u16> + Tr<u8, u8>; } trait Q { // This didn't compile type T: Tr<u8, u8> + Tr<u16, u16>; } #[allow(dead_code)] fn f<S: P>() { <S as P>::T::exec(0u8, 0u8) } #[allow(dead_code)] fn g<S: Q>() { // A mismatched types error was emitted on this line. <S as Q>::T::exec(0u8, 0u8) } // Another reproduction of the same issue trait Trait { type Type: Into<Self::Type1> + Into<Self::Type2> + Copy; type Type1; type Type2; } #[allow(dead_code)] fn foo<T: Trait>(x: T::Type) { let _1: T::Type1 = x.into(); let _2: T::Type2 = x.into(); } fn main() { } </ins>
Change:
Nominating for milestone 5, production-ready
Can't be done without running resolve.
should be optional at most, as sometimes you want to see them
just a bug, removing milestone/nomination.
Still relevant though parenting to metabug on rustdoc_ng
/cc This would involve looking at the visibility of the associated trait and excluding the impl from the list if it's not public.
Didn't find a trait to test it with but it should be done now.

Discussion:
use syntax; use syntax::ast; use syntax::ast_util; <ins> use syntax::attr; </ins> use syntax::attr::AttributeMethods; use std;

} } <ins> // This is a rough approximation that gets us what we want. impl<'self> attr::AttrMetaMethods for &'self Attribute { fn name(&self) -> @str { match **self { Word(ref n) | List(ref n, _) | NameValue(ref n, _) => n.to_managed() } } fn value_str(&self) -> Option<@str> { match **self { NameValue(_, ref v) => Some(v.to_managed()), _ => None, } } fn meta_item_list<'a>(&'a self) -> Option<&'a [@ast::MetaItem]> { None } fn name_str_pair(&self) -> Option<(@str, @str)> { None } } </ins> #[deriving(Clone, Encodable, Decodable)] pub struct TyParam { name: ~str,

use extra::sort; use syntax::ast; <ins> use syntax::attr; </ins> use clean; use doctree;

impl<'self> fmt::Default for Item<'self> { fn fmt(it: &Item<'self>, fmt: &mut fmt::Formatter) { <ins> match attr::find_stability(it.item.attrs.iter()) { Some(stability) => { write!(fmt.buf, "<a class='stability {lvl}' title='{reason}'>{lvl}</a>", lvl = stability.level.to_str(), reason = match stability.text { Some(s) => s, None => @"", }); } None => {} } </ins> // Write the breadcrumb trail header for the top write!(fmt.buf, "<h1 class='fqn'>"); match it.item.inner {

float: left; padding: 20px; } <ins> .stability { border-left: 5px solid #000; border-radius: 3px; padding: 0 3px; float: right; background: #fff; text-transform: lowercase; } .stability.Deprecated { border-color: #D60027; color: #880017; } .stability.Experimental { border-color: #EC5315; color: #a53c0e; } .stability.Unstable { border-color: #FFD700; color: #b39800; } .stability.Stable { border-color: #AEC516; color: #7c8b10; } .stability.Frozen { border-color: #009431; color: #007726; } .stability.Locked { border-color: #0084B6; color: #00668c; } </ins>

} /// The available stability levels. <del> #[deriving(Eq,Ord,Clone)] </del> <ins> #[deriving(Eq,Ord,Clone,ToStr)] </ins> pub enum StabilityLevel { Deprecated, Experimental,
Change:
I'd really expect this to just work: All types should implement , as this conversion is always possible and free.

Discussion:
} <ins> #[stable(feature = "from_nonzero", since = "1.31.0")] impl From<$Ty> for $Int { fn from(nonzero: $Ty) -> Self { nonzero.0 .0 } } </ins> impl_nonzero_fmt! { (Debug, Display, Binary, Octal, LowerHex, UpperHex) for $Ty }

_ => panic!("Expected the const item as a pattern to match.") } } <ins> #[test] fn test_from_nonzero() { let nz = NonZeroU32::new(1).unwrap(); let num: u32 = nz.into(); assert_eq!(num, 1u32); } </ins>
Change:
This code: should not pattern-match on , but rather call its method to get its type. What this means is that should inline as well as (but today it doesn't). cc
Actually it should handle both cases, I think. Handling the constant is useful when the type has been erased but constant propagation managed to propagate the actual function anyway.
It's type-based today, but it only handles the case. While handling function pointer types based on the value would be interesting, it's not done today.
Working on this one :)

Discussion:
// Only consider direct calls to functions let terminator = bb_data.terminator(); if let TerminatorKind::Call { <del> func: Operand::Constant(ref f), .. } = terminator.kind { if let ty::FnDef(callee_def_id, substs) = f.ty.sty { </del> <ins> func: ref op, .. } = terminator.kind { if let ty::FnDef(callee_def_id, substs) = op.ty(caller_mir, self.tcx).sty { </ins> if let Some(instance) = Instance::resolve(self.tcx, param_env, callee_def_id,

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -Z span_free_formats // Tests that MIR inliner works for any operand fn main() { println!("{}", bar()); } #[inline(always)] fn foo(x: i32, y: i32) -> bool { x == y } fn bar() -> bool { let f = foo; f(1, -1) } // END RUST SOURCE // START rustc.bar.Inline.after.mir // ... // bb0: { //     ... //     _0 = Eq(move _3, move _4); //     ... //     return; // } // ... // END rustc.bar.Inline.after.mir </ins>
Change:
In (not yet merged in), I had to hardcode various constants due to limitations in the stage0 compiler that appear to have been fixed by others in the meantime.
I'm insufficiently familiar with the release process to judge how such a change should land. So I'm going to assign this to you; if you unassign it from yourself, please also de-milestone it.
Is this necessary for 0.6?
Just code cleanup. Demilestone.

Discussion:
Mips } <del> // FIXME(#5423) After a snapshot, we can change these constants: // const IntelBits: u32 = (1 << (X86 as uint)) | (1 << X86_64 as uint)); // const ArmBits: u32 = (1 << (Arm as uint)); static IntelBits: u32 = 1 | 2; static ArmBits: u32 = 4; </del> <ins> static IntelBits: u32 = (1 << (X86 as uint)) | (1 << (X86_64 as uint)); static ArmBits: u32 = (1 << (Arm as uint)); </ins> struct AbiData { abi: Abi,
Change:
Found this while experimenting with the right FFI type to declare a (not ) symbol in an block. Credit to for the original code sample that I tweaked to end up with this error. This produces an ICE on nightly, or a segfault on stable. Code: Result:
visited for triage. General consensus was that going from a segfault to an ICE (an the ICE is preceded by a warning pointing you to what is wrong in your code), does not exactly seem like a regression.
is going to mentor how to make this even nicer.
I don't consider it a regression; on the contrary, turning a segfault into an ICE seems like an improvement. Still a bug, though. :)

Discussion:
ifdef CFG_WINDOWSY_$(1) $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS) $$(Q)$$(MAKE) -C $$(S)src/libuv/  <ins> CFLAGS="$$(CFG_GCCISH_CFLAGS)"  LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS)"  </ins> builddir_name="$$(CFG_BUILD_DIR)/rt/$(1)/libuv"  OS=mingw  V=$$(VERBOSE) else ifeq ($(OSTYPE_$(1)), linux-androideabi) $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS) $$(Q)$$(MAKE) -C $$(S)src/libuv/  <del> CFLAGS="$$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)"  LDFLAGS="$$(LIBUV_FLAGS_$$(HOST_$(1)))"  </del> <ins> CFLAGS="$$(CFG_GCCISH_CFLAGS) $$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)"  LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS) $$(LIBUV_FLAGS_$$(HOST_$(1)))"  </ins> CC="$$(CC_$(1))"  CXX="$$(CXX_$(1))"  AR="$$(AR_$(1))" 

else $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS) $$(Q)$$(MAKE) -C $$(S)src/libuv/  <del> CFLAGS="$$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)"  LDFLAGS="$$(LIBUV_FLAGS_$$(HOST_$(1)))"  </del> <ins> CFLAGS="$$(CFG_GCCISH_CFLAGS) $$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)"  LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS) $$(LIBUV_FLAGS_$$(HOST_$(1)))"  </ins> CC="$$(CC_$(1))"  CXX="$$(CXX_$(1))"  AR="$$(AR_$(1))"
Change:
On target (and ) any binary compiled with lto will fail with on latest stable (1.29.0 as of this time). After some searching it seems the culprit is which was meant to fix until musl 1.1.20 was out. Unfortunately the patch for musl used in that pull request broke . This was later fixed in which also landed in musl 1.1.20.

Discussion:
export CFLAGS="-fPIC $CFLAGS" <del> # FIXME: remove the patch when updating to 1.1.20 MUSL=musl-1.1.19 </del> <ins> MUSL=musl-1.1.20 </ins> # may have been downloaded in a previous run if [ ! -d $MUSL ]; then curl https://www.musl-libc.org/releases/$MUSL.tar.gz | tar xzf - <del> # Patch to fix https://github.com/rust-lang/rust/issues/48967 cd $MUSL &&  curl "https://git.musl-libc.org/cgit/musl/patch/?id=610c5a8524c3d6cd3ac5a5f1231422e7648a3791" | patch -p1 &&  cd - </del> fi cd $MUSL
Change:
Note that I am using , not the FreeBSD port.
Output for the same code on macOS -- notice that appears on frame 6, as expected.
There's a downstream patch for this (found through ) Upstreamed path to gcc: (don't know how to tell if it's been merged)
I looked at gcc git and that patch is not there. It also isn't in (I'm not sure anymore if one repository is canonical or if merges are done both ways).
By the way, mounting fixes this. But mounting is considered a Linuxism so it would be best if this weren't necessary on FreeBSD.
I'd suggest sending the patch as a PR to the aforementioned libbacktrace repository, then once it lands, also update the libbacktrace in rust-lang-nursery.

Discussion:
[[package]] name = "backtrace" <del> version = "0.3.45" </del> <ins> version = "0.3.46" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "ad235dabf00f36301792cfe82499880ba54c6486be094d1047b02bacb67c14e8" </del> <ins> checksum = "b1e692897359247cc6bb902933361652380af0f1b7651ae5c5013407f30e109e" </ins> dependencies = [ "backtrace-sys", "cfg-if",

[[package]] name = "backtrace-sys" <del> version = "0.1.34" </del> <ins> version = "0.1.35" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "ca797db0057bae1a7aa2eef3283a874695455cecf08a43bfb8507ee0ebc1ed69" </del> <ins> checksum = "7de8aba10a69c8e8d7622c5710229485ec32e9d55fdad160ea559c086fdcd118" </ins> dependencies = [ "cc", "compiler_builtins",

[dependencies.backtrace_rs] package = "backtrace" <del> version = "0.3.44" </del> <ins> version = "0.3.46" </ins> default-features = false # without the libstd `backtrace` feature, stub out everything features = [ "rustc-dep-of-std" ] # enable build support for integrating into libstd
Change:
Running on I get one failed test as shown below. This is the first time I've run the tests on this target some I'm unsure if it's a regression. Nightly commit CC ?
I think that's some flavor of On stdsimd/packedsimd we work around this by falling back to scalar code instead, so this shouldn't be used anywhere in the ecosystem on aarch64 anyways. The "fix" for this is to just ignore this test on aarch64.
Update: LLVM PR36796 is fixed.
It's not merged to Rust's LLVM fork.
How about now?
FWIW was released in LLVM 9 which rustc currently uses, so this ought to be fixed.
Seems like we need to add a test in that case.
No need for a new test, reverting (not ignoring that test on AArch64 any longer) should suffice. Although I'm not sure if we have CI for that target.
I'd suggest to wait for the LLVM 10 upgrade, which will address some additional issues. While LLVM 9 fixed the majority of this, there were still issues with ordered and non-fast reductions in some cases.
Triage: is already "reverted" in and we're on LLVM 10 now. I think there's nothing more we could do here? Closing.

Discussion:
#![allow(non_camel_case_types)] // ignore-emscripten <ins> // ignore-aarch64 FIXME: https://github.com/rust-lang/rust/issues/54510 </ins> // Test that the simd_reduce_{op} intrinsics produce the correct results.
Change:
When compiling my project on the branch "crashing" (which just has a lot of irrelevant things commented out) commenting out this array (and the same similar arrays from the other files in that directory) causes it to not crash. : rustc 1.30.0-nightly ( 2018-09-17) binary: rustc commit-hash: commit-date: 2018-09-17 host: x86_64-pc-windows-msvc release: 1.30.0-nightly LLVM version: 8.0 Backtrace:
Could you create and copy here a minimized example of the problem?
I was able to get this to throw have the same panic If you remove the type from , it will not panic. The length of does not seem to effect it. Should note this is on a slightly newer compiler (just performed rustup update on my current computer before performing this) Backtrace:
No longer reproduces in current stable.
Can confirm, no longer having issues with same implementation.

Discussion:
<ins> // run-pass pub trait Stage: Sync {} pub enum Enum { A, B, } impl Stage for Enum {} pub static ARRAY: [(&Stage, &str); 1] = [ (&Enum::A, ""), ]; fn main() {} </ins>
Change:
The layout for small screens hides the fully qualified name (and associated controls) and leaves some blank space. Compare with : !

Discussion:
h1.fqn { border-bottom: 1px dashed; margin-top: 0; <del> overflow: auto; </del> } h2, h3:not(.impl):not(.method):not(.type):not(.tymethod), h4:not(.method):not(.type):not(.tymethod):not(.associatedconstant) { border-bottom: 1px solid;