-
Notifications
You must be signed in to change notification settings - Fork 305
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: hyperium/http
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v0.2.6
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: hyperium/http
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: v0.2.7
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 8 commits
- 12 files changed
- 7 contributors
Commits on Apr 15, 2022
-
Configuration menu - View commit details
-
Copy full SHA for ec616ed - Browse repository at this point
Copy the full SHA ec616edView commit details
Commits on Apr 16, 2022
-
Make HeaderName::from_static const (#499)
... plus some clean-up. It was only after I came up with the scheme using `const fn from_bytes(&[u8]) -> Option<StandardHeader>` that I noticed the debug+wasm32-wasi version of `parse_hdr`, which had something very similar. While cleaning up that function, I realized it still would still panic if an attempted name was too long, which had been fixed for all other targets and profiles in #433. Then, I thought it would be worth seeing if the use of `eq!` in the primary version of `parse_hdr` still made any difference. And, it would not appear so. At least not on x86_64, nor wasm32-wasi run via wasmtime. I've run the benchmarks a number of times now, and it seems the only significant performance change anywhere is actually that of `HeaderName::from_static` itself, which now seems to run in about 2/3 the time on average. Unfortunately, `const fn` still cannot `panic!`, but I've followed the lead from `HeaderValue::from_static`. While that version required 1.46, this new function requires 1.49. That is almost 8 months old, so hopefully this isn't too controversial!
Configuration menu - View commit details
-
Copy full SHA for d8b35db - Browse repository at this point
Copy the full SHA d8b35dbView commit details
Commits on Apr 25, 2022
-
Configuration menu - View commit details
-
Copy full SHA for 4fb67bc - Browse repository at this point
Copy the full SHA 4fb67bcView commit details
Commits on Apr 26, 2022
-
Configuration menu - View commit details
-
Copy full SHA for f4cff03 - Browse repository at this point
Copy the full SHA f4cff03View commit details -
Configuration menu - View commit details
-
Copy full SHA for d82aa29 - Browse repository at this point
Copy the full SHA d82aa29View commit details -
Configuration menu - View commit details
-
Copy full SHA for bd30ce0 - Browse repository at this point
Copy the full SHA bd30ce0View commit details
Commits on Apr 28, 2022
-
From impls of PathAndQuery and Authority for Uri (#538)
* From impls of PathAndQuery and Authority for Uri A Uri may logically hold only an Authority or only a PathAndQuery. Should an application want to make such Uris, it would be easier to safely create them by first making just an Authority or just a PathAndQuery, then cheaply convert them directly into a Uri. * Fix Uri docs The doc comments for `impl From<Uri> for Parts` actually described `Uri::from_parts`.
Configuration menu - View commit details
-
Copy full SHA for c1f309e - Browse repository at this point
Copy the full SHA c1f309eView commit details -
Configuration menu - View commit details
-
Copy full SHA for 95ad79b - Browse repository at this point
Copy the full SHA 95ad79bView commit details
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v0.2.6...v0.2.7